Interactive networking systems

ABSTRACT

A networking system may comprise a web site serviced by a web server assembly. The web site may generally comprise a combination of the following components: a crediting system, a chat bidding system, a performance bidding system, a telephony switching system, a media interaction system, a display system, a photo management system, and a messaging system. An exemplary embodiment of the chat bidding system may comprise a plurality of common user accounts, a queue, and a featured user account. Common users of the common user accounts may pose tasks to the featured user, and may make a pledge for each task. The tasks may be stored in, and sorted by, the queue based on their pledges. A featured user of the featured user account may be presented with a highest ranked task in the queue, and may choose to respond to the task or to skip the task.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.12/237,316, filed 24 Sep. 2008, which claims priority and a benefitunder 35 U.S.C. §119(e) of U.S. Provisional Patent Application60/974,723, filed 24 Sep. 2007, and U.S. Provisional Patent Application61/059,444, filed 6 Jun. 2008. The disclosures of all of these priorapplications are hereby incorporated by reference as if fully set forthbelow.

BACKGROUND

1. Technical Field

Various aspect of the present invention relate to social andprofessional networking and, more particularly, to interactivenetworking systems for enabling interaction between one or more classesof users.

2. Description of Related Art

Conventional social and professional networking systems enable users tointeract with one another via various networking protocols. Thesesystems provide a variety of services, but they generally lack theability to classify a user's network of contacts to provide varyinglevels of communication capabilities among different levels of users.

Such conventional systems are also not designed for serving as social orprofessional networking and communications platforms where certainindividuals are highly sought after communication partners. For example,while celebrities are able to register and utilize conventionalnetworking systems to communicate directly with their friends andacquaintances, celebrities do not currently have the ability toselectively allow communications from their fans.

These conventional systems are also generally limited in how they allowvarious users to communicate. For example, conventional systemsgenerally limit inter-user communications to chat rooms, message boards,and/or private email messages.

Therefore, there is a need in the art for a system that providesincreased communications capabilities.

There is also a need for a networking system whereby users can controlcommunication capabilities pertaining to communications with otherusers, where such controls may be at least partially based on a class ofsuch users.

There is a further need for such a networking system having safetycontrols enabling member interactions while allowing a receiving partyto establish criteria controlling receipt of communications.

There is a further need for such a networking community, in whichcelebrities may communicate directly with fans in a virtual environmentproviding real-time interaction.

It is to such a networking system that that the present invention isdirected.

SUMMARY

Exemplary embodiments of the present invention may include interactivenetworking systems providing various communication features. Suchembodiments may allow multiple user classes. In an exemplary embodiment,the networking system may comprise any or all of various components,including a crediting system, a chat bidding system, a performancebidding system, a telephony switching system, a media interactionsystem, a display system, a photo management system, and a messagingsystem.

To enable operation of such components of the networking system, thenetworking system may additionally comprise a server assembly. Theserver assembly may comprise one or more web servers for hosting the website. A user may interact with the web site through a web client adaptedto display the web site. The web client may receive requests from theuser and direct such requests to the server assembly. The serverassembly may call various operations or programs to implement componentsand operations of the web site. The server assembly may send responsesto user requests through the web client to the user.

Each user of the web site may have, or be associated with, a useraccount for accessing the web site. According to the crediting system ofthe networking system, each user account may be associated with a creditaccount for purchasing services from the web site. The credit accountmay represent virtual funds for use on the web site.

The chat bidding system, if included, may enable common users to posetasks to a featured user in an organized manner. The chat bidding systemmay generally comprise a featured user, a plurality of common users, anda tasks queue.

The featured user may represent a person or entity in which the commonusers have interest. For example, the featured user may be a celebrity,a doctor, a counselor, or the like. The featured user may use a featureduser account to interact with the web site.

The common users may have an interest in the featured user. For example,the common users may be fans of the featured user. Through the chatbidding system, the common users may pose tasks to the featured user. Acommon user may pledge credits for a task, thereby associating the taskwith a bid value. The amount of the bid value may be debited from theuser's credit account.

The tasks queue may comprise hardware, software, or a combinationthereof, in communication with the server assembly. The tasks queue mayorganize the tasks in an order corresponding to the bids associated withthe tasks.

Through a web client in communication with the server assembly, thefeatured user may be presented with the tasks in an order determined bythe tasks queue and, therefore, determined by the bids associated withthe tasks. For each presented task, the featured user may dispatch thetask by responding to or skipping the task.

If included, the performance bidding system may enable users to performon the web site in an organized manner. The performance bidding systemmay comprise a plurality of users and a performance queue.

Each user may request an opportunity to perform, and may associate suchrequest with a bid. The bid value may represent a number of creditsdeducted from the user's account in return for the user's performance.

The performance queue may comprise hardware, software, or a combinationthereof, in communication with the server assembly. The performancequeue may organize the performance requests in an order corresponding tothe bids associated with the requests. A user may be allowed to performon the web site when the user's request reaches a top of the queue.

If included in the web site, the telephony switching system may enableanonymous contact between two parties having user accounts on the website. The telephony switching system may generally comprise a firstcommunication device, a second communication device, a service center,and a telephony switch.

The first communication device and second communication device may beregistered with the service center, and such registration may occur overthe web site. Each registration may include a set of contact rulesspecifying who may connect to the applicable communication device, andwhen such connections may occur.

A first user associated with the first communication device may requesta connection to a second user associated with the second communicationdevice. The service center may receive the request and, based on thecontact rules, may determine whether the requested connection isallowed.

The telephony switch may be in communication with the service center. Ifthe requested connection is allowed, the service center may forward theconnection request to the telephony switch. In turn, the telephonyswitch may connect the first communication device to the secondcommunication device. Accordingly, the two communication devices may beconnected to each other without phone numbers of either communicationdevice being shared with the other communication device.

If included in the web site, the media interaction system may enable afirst user to interact with a second user by extending a media object tothe second user. The media object may be customizable, and may comprisevarious media, including animations, audio, or text. The media objectmay overlay other objects displayed on a client computer of the firstuser and a client computer of the second user.

If included, a display system may enable color and theme changes of theweb site as viewed by a web client. Based on a user request, a colorscheme and theme of the web site may be altered in response to a userrequest.

The photo management system, if included in the web site, may enableusers of the web site to manage and edit digital images stored on theserver assembly. The photo management system may comprise an imagelibrary and an image editor. The image library may contain imagesselected or created by a particular user, and the image editor mayenable the user to edit images in the image library.

Additionally, a messaging system, if included, may enable a first userto leave a message on a virtual message board of a second user. Themessaging system may comprise a message area, one or more graphicaltools, and a color selector. The first user may select a graphical tooland a color, and may then modify an image of the message area in amanner customizable based on the chosen graphical tool and color.

These and other objects, features, and advantages of the interactivenetworking system will become more apparent upon reading the followingspecification in conjunction with the accompanying drawing figures.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates an architecture of a client computer utilizing aninteractive networking system, in accordance with an exemplaryembodiment of the present invention.

FIG. 2 illustrates an architecture of a server assembly of thenetworking system, according to an exemplary embodiment of the presentinvention.

FIG. 3 illustrates a block diagram of the networking system, accordingto an exemplary embodiment of the present invention.

FIG. 4 illustrates a block diagram of a chat bidding system of thenetworking system, according to an exemplary embodiment of the presentinvention.

FIG. 5 illustrates a flow diagram of an operation of the chat biddingsystem of the networking system, according to an exemplary embodiment ofthe present invention.

FIG. 6 illustrates a flow diagram of a process of a featured userinitiating and participating in a chat bidding session of the chatbidding system, according to an exemplary embodiment of the presentinvention.

FIGS. 7A-7B illustrate flow diagrams of a process of the featured usermoderating the chat bidding session of the chat bidding system,according to an exemplary embodiment of the present invention.

FIG. 8 illustrates a flow diagram of a process of a common user joiningthe chat bidding session of the chat bidding system, according to anexemplary embodiment of the present invention.

FIG. 9 illustrates a flow diagram of a process of the user participatingin the chat bidding session of the chat bidding system, according to anexemplary embodiment of the present invention.

FIG. 10 illustrates a flow diagram of an operation of a performancebidding system of the networking system, according to an exemplaryembodiment of the present invention.

FIG. 11A illustrates a process of registering a communication devicewith the telephony switching system of the networking system, accordingto an exemplary embodiment of the present invention.

FIGS. 11B-11C illustrate block diagrams of a telephony switching systemof the networking system, according to an exemplary embodiment of thepresent invention.

FIG. 12 illustrates a flow diagram of a method of handling a connectionrequest from a calling party to a receiving party in the telephonyswitching system of the networking system, according to an exemplaryembodiment of the present invention.

FIG. 13 illustrates a flow diagram of an operation of a mediainteraction system of the networking system, according to an exemplaryembodiment of the present invention.

FIG. 14 illustrates a flow diagram of an operation of a photo managementsystem of the networking system, according to an exemplary embodiment ofthe present invention.

FIG. 15 illustrates a flow diagram of an operation of a photo editor ofthe photo management system of the networking system, according to anexemplary embodiment of the present invention.

FIG. 16 illustrates a flow diagram of an implementation of the photoeditor of the photo management system, according to an exemplaryembodiment of the present invention.

FIG. 17 illustrates a flow diagram of a process of displaying an imagein the photo management system of the networking system, according to anexemplary embodiment of the present invention.

FIG. 18 illustrates a web page of a messaging system of the networkingsystem, according to an exemplary embodiment of the present invention.

FIG. 19 illustrates a flow diagram of an operation of leaving a messagethrough a messaging system of the networking system, according to anexemplary embodiment of the present invention.

FIG. 20 illustrates a flow diagram of an operation of retrievingmessages from the messaging system of the networking system, accordingto an exemplary embodiment of the present invention.

FIG. 21 illustrates a flow diagram of a general operation of themessaging system of the networking system, according to an exemplaryembodiment of the present invention.

DETAILED DESCRIPTION

To facilitate an understanding of the principles and features of theinvention, various illustrative embodiments are explained below. Inparticular, the invention is described in the context of being aweb-based interactive networking system for celebrities and their fans.Embodiments of the invention, however, are not limited to web-basedimplementations, or to use by celebrities and fans. Rather, embodimentsof the invention may be used for networking and interaction betweenvarious entities and individuals in various environments. For example,and not limitation, doctors, counselors, sports figures, and politiciansmay benefit from the embodiments of the invention.

Throughout the present description, the present invention is describedas embodied in a web environment. However, those of skill in the artwill recognize that the concepts of the invention are not limited to aweb environment and could be applied to various other systems.Accordingly, reference to web components is for convenience, and suchreferences should not be considered limiting.

For example, and not limitation, embodiments of the present networkingsystem may be implemented in media centers, video game consoles,operating systems, and virtual machines. Media centers may includetelevision, telephone, and internet technologies, any of which mayutilize various embodiments of the present networking system. Further,video game consoles now implement social networking, internetcommunications, video recording, and digital file downloading.Interactive networking may be useful in such video consoles, and may beprovided by embodiments of the present networking system. Operatingsystems, such as Linux™, Mac OS X™, and Microsoft Windows™, enablecertain technologies to be implemented within the operating systemoutside of the framework of the World Wide Web. Accordingly, embodimentsof the networking system may be utilized in such operating systemswithout use of the World Wide Web. In addition, technologies such asJava™ and Adobe Air™ allow functionality outside the scope of the WorldWide Web, in the context of “virtual machines,” which may utilize thepresent networking system.

Exemplary embodiments of the networking system may contain componentsthat may be utilized in a wide variety of applications. Some exemplaryembodiments may be for personal entertainment, and others may be forprofessional use. Professional uses of the networking system mayinclude, without limitation, medical personnel recruiting, educationalapplications, and various other applications matching persons topersons, persons to services, or persons to products. The networkingsystem may comprise various classes of users, and may enable one or moreuser classes to control access and duration of interaction betweenthemselves and users of one or more other user classes.

The components described hereinafter as making up various elements ofthe invention are intended to be illustrative and not restrictive. Manysuitable components that would perform the same or similar functions ascomponents described herein are intended to be embraced within the scopeof the invention. Such other components not described herein mayinclude, but are not limited to, for example, components developed afterdevelopment of the invention.

Various embodiments of the present invention comprise interactivenetworking systems. Referring now to the figures, wherein like referencenumerals represent like parts throughout the views, various embodimentsof the networking system will be described in detail.

FIG. 1 illustrates a computer architecture for a client computer 102, inaccordance with an exemplary embodiment of the present invention. Theclient computer 102 may be used to access the web site 310 (FIG. 3).Those skilled in the art will recognize that the general architecturedescribed with reference to FIG. 1 is for example only, and may bemodified to accommodate various embodiments of the networking system andparticular operational environments. As shown in FIG. 1, the clientcomputer 102 may comprise a central processing unit 105 (“CPU”) and oneor more system memories 107, such as a random access memory 109 (“RAM”)and a non-volatile memory, such as a read-only memory (“ROM”) 111. Theclient computer 102 may further comprise a system bus 112 couplingtogether the memory 107, the CPU 5, and various other components. Abasic input/output system containing routines to assist in transferringinformation between components of the client computer 102 may be storedin the ROM 111. Additionally, the client computer 102 may include a massstorage device 114 for storing an operating system 116, applicationprograms, and other program modules.

The mass storage device 114 is generally connected to the CPU 105through a mass storage controller (not shown) connected to the bus 112.The mass storage device 114 and its associated computer-readable mediaprovide non-volatile storage for the client computer 102. Although thedescription of computer-readable media contained herein generally refersto a mass storage device, such as a hard disk or CD-ROM drive, it willbe appreciated by those skilled in the art that computer-readable mediamay include any available media accessible by the client computer 102 ora server assembly 230 (FIG. 2).

By way of example, and not limitation, the computer-readable media maycomprise computer storage media and communication media. Computerstorage media may include volatile and non-volatile, removable andnon-removable media implemented in any method or technology for storageof information, such as computer-readable instructions, data structures,program modules, or other data. Computer storage media includes, but isnot limited to, RAM, ROM, EPROM, EEPROM, flash memory, other solid statememory technology, CD-ROM, digital versatile disks (“DVD”), otheroptical storage, magnetic cassettes, magnetic tape, magnetic diskstorage, other magnetic storage devices, or any other media that may beused to store the desired data and may be accessible by the clientcomputer 102 or the server assembly 230. Computer-readable instructionson the storage media of the client computer 102 may include, forexample, instructions for implementing processes, preferably client-sideprocesses, of the networking system 300.

According to various embodiments, the client computer 102 may operate ina networked environment using logical connections to remote computers,such as the server assembly 230, through a network 118, such as theInternet. The client computer 102 may connect to the network 118 througha network interface unit 120 connected to the bus 112. It will beappreciated that the network interface unit 120 may also be utilized toconnect to other types of networks and remote computer systems.

The client computer 102 may also include an input/output controller 122for receiving and processing input from a number of other devices,including a keyboard, mouse, or electronic stylus. The input/outputcontroller 122 may provide output to a display screen, a printer, orother type of output device.

A number of program modules and data files may be stored in the massstorage device 114 and RAM 109 of the client computer 102. Such programmodules and data files may include an operating system 116 suitable forcontrolling operations of a networked personal computer. A web browserapplication program, or web client 124, may also be stored on the massstorage device 114 and the RAM 109. The web client 124 may comprise anapplication program for requesting and rendering web pages 126 createdin Hypertext Markup Language (“HTML”) or other types of markuplanguages. The web client 124 may also be capable of executing scriptsthrough the use of a scripting host. The scripting host executes programcode expressed as scripts within the browser environment.

The web client 124 may be operative to execute one or more client sideobjects. As discussed briefly above, client side objects are executableobjects that may be identified in a web page 126 and executed inconjunction with the rendering of the web page 126. For instance, Java™applets or ActiveX™ controls may be identified on a web page 126 andrendered by the web client 124 to generate a portion of the web page 126display.

According to an exemplary embodiment of the invention, the web client124 may be further operative to utilize client side objects called webpart objects 128A-128C, or web parts. Web part objects 128A-128C arereusable client side objects that stand and contain web-based contentsuch as Extensible Markup Language (“XML”), HTML, and scripts. Web parts128A-128C have a set of standard properties that control how they arerendered. These properties enable web parts to be storage-neutral andreusable. Because web parts 128A-128C adhere to a common standard, theymay be stored in libraries, which may be utilized to create a variety ofweb pages 126. Web pages 126 that include web part objects 128A-128C maybe referred to herein as web part pages.

Referring now to FIG. 2, a server assembly 230 utilized in variousexemplary embodiments of the networking system 300 (FIG. 3) will bedescribed. The server assembly 230 may service the web site 310 byreceiving and responding to requests from web clients 124. The serverassembly 230 may comprise various combinations of hardware and softwarefor servicing the web site 310. Those skilled in the art will recognizethat the server assembly 230 described in FIG. 2 is an exemplary serverconfiguration and may be modified to accommodate various embodiments ofthe networking system 300. As shown in FIG. 2, the server assembly 230may include many of the conventional computing components included inthe client computer 102 and described above with respect to FIG. 1. Inparticular, the server assembly 230 may include a CPU 105, a networkinterface unit 120 connected to a network 118, such as the Internet, asystem memory 107, and a mass storage device 114.

The mass storage device 114 utilized by the server assembly 230 maytypically be operative to store an operating system 116 suitable forservicing the web site 310 and controlling operations of a servercomputer. The mass storage device 114 and its associatedcomputer-readable storage media provide non-volatile storage for theserver assembly 230. Computer storage media may include volatile andnon-volatile, removable and non-removable media implemented in anymethod or technology for storage of information, such ascomputer-readable instructions, data structures, program modules, orother data. Computer-readable instructions on the computer-readablemedia of the server assembly 230 may include, for example, instructionsfor implementing processes, preferably server-side processes, of thenetworking system 300.

The server assembly 230 may utilize a web server application 232. Theweb server application 232 may receive and respond to requests from webclients 124 at remote computers, such as the client computer 102, forweb pages 126 located at or accessible to the server assembly 230. Itwill be appreciated that web pages 126, as described herein, includeboth those pages stored statically and utilizing only HTML, as well aspages generated dynamically through use of server-side scriptingtechnologies.

According to various embodiments of the networking system 300, the webserver application 232 may receive requests for web pages 126 thatinclude one or more web parts 128A-128C. As discussed above, web parts128A-128C comprise client-side objects that may be used by the webclient 124 when displaying a web page 126.

FIG. 3 illustrates a block diagram of the networking system 300,according to an exemplary embodiment of the present invention. Thenetworking system 300 may operate in an environment of the clientcomputer 102 and the server assembly 230. As shown in FIG. 3, anexemplary embodiment of the networking system 300 may comprise aninteractive networking web site 310, the server assembly 230, and a website manager 315. The client computer 102 may interact with the web site310 and, accordingly, the server assembly 230 through the web client 124at the client computer 102.

The web site 310 may enable interaction between and among one or morefeatured users and a plurality of common users. The featured users mayinteract with one another via the web site 310, and similarly, thecommon users may interact with one another via the web site 310.Additionally, the common users may desire some level of interaction withthe featured users, and the featured users may desire some level ofprivacy in their interactions with the common users. For example, afeatured user may be a celebrity, and a set of common users may be fansof the celebrity. The web site 310 may provide a virtual environment forsuch interactions.

The server assembly 230 may service the web site 310. The serverassembly 230 may operate as discussed in detail above, or in variousmanners for providing services to client computers 102 over a network.

The web site manager 315 may manage the web site 310, act asadministrator of the web site 310, and provide customer service to usersof the web site 310. Preferably, the web site manager 315 may be one ormore humans or entities, but may also comprise computing devices andautomated services.

The web site 310 may generally comprise any combination of the followingcomponents: a crediting system 320, a chat bidding system 330, aperformance bidding system 340, a telephony switching system 350, amedia interaction system 360, a display system 370, a photo managementsystem 380, and a messaging system 390. Each component of the web site310 may provide various services as described further below.

Crediting System

The web site 310 may provide a crediting system 320 for providing usersa means to purchase services of the web site 310. Each user may have auser account, and the user account may be associated with the user'shistory of activities on the web site 310. According to the creditingsystem 320, the user account may include a credit account representingvirtual credits allotted to the user. The credits may be used topurchase services from the web site 310, or products and services fromentities associated with the web site 310.

The web site 310 may provide multiple categories of credits, such asuniversal credits and limited credits. Universal, or non-promotional,credits may be purchasable by the user. The user may purchase universalcredits from the web site manager 315 via the web site 310, over a phonecall, or via various other means of communicating a desire to purchasecredits. In contrast, limited, or promotional, credits may be awarded tothe user based on promotions. The web site 310 may separately accountfor universal and limited credits. However, the web site 310 may presentthe user with either a combined total of credits or with separate totalsfor each of universal and limited credit accounts. As mentioned above,various services of the web site 310 may be purchased with credits.Preferably, predetermined exclusive services of the web site 310 may bepurchased only with universal credits, while non-exclusive services maybe purchased with universal credits, limited credits, or variouscombinations thereof.

The web site 310 may provide various categories of user membership. Forexample, and not limitation, the web site 310 may provide featured useraccounts for featured users and common user accounts for common users.Preferably, at least the common users may purchase services through theweb site 310 with their credit accounts. Such services may includeopportunities to interact with the featured users. Purchasable servicesmay be services of the chat bidding system 330, the performance biddingsystem 340, the telephony switching system 350, the media interactionsystem 360, the display system 370, the photo management system 380, themessaging system 390, and/or other web service systems.

For purchase of services on the web site 310, the web site 310 mayimplement a predetermined scheme for determining which credits aredebited from the purchasing user's credit account. For example, and notlimitation, a purchase of an exclusive service may automatically debitthe user's universal credits. For a purchase of a non-exclusive service,the user may be allowed to specify which credits are debited for thepurchase. Alternatively, the web site 310 may implement afirst-in-first-out accounting, in which the first credits placed intothe user's credit account are the first credits debited from the usersaccount, or a last-in-first-out accounting, in which the last creditsplaced in the user's account are the first credits debited from the useraccount. As another option, the web site 310 may automatically debit anyavailable limited credits before universal credits for the purchase ofnon-exclusive services.

Through the use of credit accounts, common users may interact withfeatured users, and as a result, common users, featured users, and theweb site manager 315 may profit from such interaction. Common users maybenefit by fulfilling desires to interact with featured users, such ascelebrities, who might otherwise be inaccessible to the common users.Featured users may interact with common users and, thereby, increasetheir popularity and fan bases. Further, featured users may haveagreements with the web site manager 315, whereby featured users sharein revenues generated by the web site 310 or whereby the web sitemanager 315 donates revenues from the web site 310 to favored charitiesof the featured users. Additionally, the web site manager 315 may reapfinancial benefits through selling credits to common users.

Chat Bidding System

The chat bidding system 330 of the web site 310 may provide an organizedcommunity in which common users may interact with a featured user. FIG.4 illustrates a block diagram of an exemplary chat bidding system 330 ofthe web site 310. As shown in FIG. 4, an instance of the chat biddingsystem 330, a chat bidding session, may comprise a plurality of commonuser accounts 410, a tasks queue 420, and a featured user account 430.

Each chat bidding session of the chat bidding system 330 may comprise aplurality of common users 415 and at least one, and preferably only one,featured user 435. Through common user accounts 410, the common users415 may pose tasks to the featured user 435. The tasks queue 420 maystore the posed tasks or references to the posed tasks. Through thefeatured user account 430, the featured user 435 may be presented withthe tasks, preferably one at a time, and may choose whether to respondto each task as it is presented.

FIG. 5 illustrates a flow diagram of an operation 500 of the chatbidding system 330 according to an exemplary embodiment of thenetworking system 300. As shown in FIG. 5, at 510, the web site 310 mayreceive a task posed by a first common user 415. The task may beaccompanied by a pledge from the common user 415, and a bid valuecorresponding to the pledge may be associated with the task. At 520, thetask may be inserted into an appropriate position of the queue 420 basedon the task's associated bid value. A second task may be received from asecond common user 415 at 530, and at 540, the second task may also beinserted into an appropriate position of the queue 420. At 550, the website 310 may present the featured user 435 with a priority task, whichis the task currently at the top of the ordered queue 420. The featureduser 435 may choose to respond to the priority task, or to skip thepriority task. In an exemplary embodiment of the chat bidding system330, common users 415 whose tasks are skipped may receive refunds fortheir pledged credits. At 560, the web site 310 may respond according tothe featured user's decisions to skip or respond to the priority task.This may comprise accepting the featured user's response to the task orindicating that the priority task has been skipped.

Referring now back to FIG. 4, the common users 415 may pose tasks to thefeatured user 435. Each task may comprise a question, comment, orrequest of the posing common user 415. In posing a task, a common user415 thereby requests that the featured user 435 respond to the posedtask. Tasks may be posed in various formats. For example, a task may bea typed question, an audio challenge or other request, or various otherformats for prompting a response from the featured user 435. The website 310 may receive the tasks and, as described further below, maystore the tasks in an ordered manner through use of the queue 420.

A common user 415 may associate a bid with a posed task. The bid ispreferably a pledge of credits from the common user's credit account. Inpledging a credit amount, the common user 415 may commit to purchase thefeatured user's response to the task for the pledged amount or,alternatively, may commit to purchase an opportunity to present the taskto the featured user 435 for the pledged amount. If the common user 415does not associate the task with a bid, a bid value for the posed taskmay be set to zero. A first exemplary embodiment of the chat biddingsystem 330 debits the common user's credit account regardless of whetherthe featured user 435 responds to the common user's task. An alternativeexemplary embodiment of the chat bidding system 330, however, debits thecredit account only if the featured user 435 is eventually presentedwith the common user's task or, alternatively, only if the featured user435 responds to the common user's task.

The tasks queue 420 may store the tasks or references to the tasks.Storage space for the tasks queue 420 may be provided on the serverassembly 230. In the tasks queue 420, tasks may be ordered based atleast partially on their bid values. In other words, a first task with afirst bid value may be ranked higher than a second task with a lower bidvalue. When a new task is posed by a common user 415, such new task maybe inserted into the tasks queue 420 based on a ranking of the bid valueof the new task. In an exemplary embodiment of the chat bidding system330, if the new task has a bid value equal to a bid value of apreviously-posed task already in the tasks queue 420, the new task maybe ranked behind the previously-posed task. The web site 310 may notifythe common user 415 of positions of his tasks in the queue 420.Additionally, the web site 310 may allow the common user 415 to alterthe bid values of his tasks and, thereby, potentially modify thepositions of his tasks in the tasks queue 420. The web site 310 may alsodisplay to the common user 415 an amount of credits required to increasea task of the common user 415 to a certain rank in the tasks queue 420.Preferably, bids for previously submitted tasks may be increased but notdecreased.

A predetermined number of highest ranked tasks in the queue 420 may havea fixed ranking order at the top of the queue 420. For example, and notlimitation, the top N tasks may be fixed such that a bid modification ofa previously lower-ranked task may not affect the positions of such topN tasks. Further, the top N tasks may be presented to the featured user435, according to their rank amongst the other top N tasks.

In some implementations of the chat bidding system 330, fixing ranks ofthe top N tasks may entail removing the top N tasks from the tasks queue420, and inserting them into a standby queue. Tasks in the standby queuemay be ordered according to when they were removed from the tasks queue420, and may be presented to the featured user 435 in an order in whichthey were inserted into the standby queue. In other words, the standbyqueue may be a first-in-first-out queue, and after a task is removedfrom the standby queue for presentation to the featured user 435, ahighest ranked task in the tasks queue 420 may be removed from the tasksqueue 420 and inserted into the standby queue. In other implementations,fixing ranks of the top N tasks may entail setting fixed positions forsuch top N tasks within the queue 420 and restricting resorting of suchtasks. In either of these implementations, any resorting or rearrangingof the queue 420 may not affect the positions of the top N tasks.

Those skilled in the art will recognize that a queue may be implementedin various manners and through use of various data structures. Thoseskilled in the art will further recognize that a queue may refer tocertain types of related data, which may, but need not, be stored incontiguous physical space. Accordingly, as used herein, the standbyqueue of the chat bidding system 330 may refer to a set of data storeddistinct from the tasks queue 420, or to a set of data sharing physicalspace with the tasks queue 420.

Fixing ranks of the top N tasks may incentivise common users 415 topledge high bid values for their tasks, because after such tasks reach apredetermined rank, their positions become fixed. Preferably, N is asmall number, such as two. A large value of N may discourage commonusers 415 by making too many of the top positions unreachable.

To increase efficiency of the networking system 300, data regardingposed tasks may be stored on the client computer 102, in addition to theserver assembly 230. A client-side application may run at the clientcomputer 102, and may cache task data on the client computer 102. In anexemplary embodiment of the networking system 300, client-side cachingmay occur locally on the client computer 102 by storing task data in anarray in the order in which the tasks were posed. The array may containtask data including, for example, question text, bid amount, and currentposition in the tasks queue 420. The order in which tasks are stored inthe array may be retained when a web page of the chat bidding session isreloaded. The client-side cache may be updated at various occurrences,such as a rank change or an update to task text or bid amount.

The web site 310 may present the featured user 435 with the prioritytask. The priority task may be the highest ranked task in the tasksqueue 420. Alternatively, if the top N tasks are removed from the tasksqueue 420 and inserted into the standby queue, the priority task may bethe highest ranked task in the standby queue. The featured user 435 maybe able to view a predetermined number of other posed tasks in additionto the priority task, but preferably, the featured user 435 must act onthe priority task before being presented with any other tasks. Alsopreferably, the featured user 435 may view only the top N tasks, whichhave fixed position in the order in which they will be presented to thefeatured user 435. In such embodiments, the featured user 435 may bepermitted to select presented tasks out of order. For each viewabletask, the featured user 435 may also view statistics related to thetask, such as the associated bid value and how long the task has been inthe queue 420.

After being presented with the priority task, the featured user 435 maychoose to respond to the priority task or to skip the priority task. Ifthe priority task is skipped, the featured user 435 may not have anotheropportunity to respond to such task unless it is again posed by a commonuser 415. By presenting the featured user 435 with each task only once,the web site 310 may provide an organized manner for the featured user435 to handle a small or large number of tasks. Additionally, commonusers 415 may be encouraged that their tasks can eventually be presentedto the featured user 435 and may, therefore, more confidently pledgecredits towards their tasks to increase a possibility that their taskswill be viewed. In an alternative embodiment of the chat bidding system330, however, the featured user 435 may be entitled to temporarily skipa task and have it represented later, preferably after the followingtask.

When a task becomes the priority task, the common user 415 who posedsuch task may become a featured common user 415. In that case, datarelating to the featured common user 415 may be displayed to othercommon users 415 and to the featured user 435. Such data may include,without limitation, the featured common user's username and picture.Additionally, other users, both common 415 and featured 435, may have anopportunity to follow a web hyperlink and, thereby, view the featuredcommon user's full profile on the web site 310. Accordingly, thefeatured common user 415 may be rewarded for his pledge in that allother parties may know who posed the priority task.

As mentioned above, the featured user 435 may choose to respond to thepriority task. The type of response given by the featured user 435 maydepend on the type of task posed. For example and not limitation, if thetask is a question, the featured user 435 may answer the question, andif the task is a request, the featured user 435 may comply with therequest. The web site 310 may receive the response of the featured user435 in various ways. For example, the web site 310 may receive anddisplay an answer to a question in the form of text. Alternatively, theweb site 310 may receive the featured user's compliance with a taskedrequest through, for example, a webcam or other recording media.

In addition to the above functions of the featured user 435, a role ofthe featured user 435 may be similar to a role of a chat moderator. Thefeatured user 435 may initiate the chat bidding session and may prompttasks from the common users 415. When initiating a chat bidding session,the featured user 435 may select a charity to share in revenuesgenerated by the chat bidding session. The featured user 435 may be ableto change the benefiting charity during the chat bidding session.Credits deducted from credit accounts of the common users 415 for posedtasks represent revenues of the chat bidding session. In predeterminedpercentages, such revenues may be divided among the web site manager315, the featured user 435, and, if indicated, the selected charity.

The featured user 435 may also have access to a synchronous alert toolon the web site 310. For example, when initiating a chat biddingsession, the featured user 435 may issue a mass notification to allcommon users 415, or to a predetermined set of common users 415, tonotify such common users 415 of the chat bidding session. In anexemplary embodiment of the chat bidding system 330, the synchronousalert tool issues a pop-up alert to common users 415.

A common user 415 may view various elements of the chat bidding session.For example, the web site 310 may display to the common user 415 a nameand biography of the featured user 435. The web site 310 may alsodisplay responses for each task to the plurality of common users 415, asin a group chat session. In other words, if the featured user 435responds to a task of a first common user 415, such response may bedisplayed to all common users 415 in a virtual group environment of theweb site 310. Additionally, each common user 415 may view and scrollthrough his own posed tasks. The common user 415 may view the queueposition of each of his tasks and may modify the bid amount of each ofhis tasks. Optionally, the common user 415 may also have access to acomplete list of posed tasks from the plurality of common users 415. Insome exemplary embodiments of the chat bidding system 330, a firstcommon user 415 may be able to pledge his credits to a task posed by asecond common user 415. Accordingly, the first common user 415 mayincrease the bid value and, potentially, the rank of a task of thesecond common user 415. Additionally, in such a scenario, the web site310 may acknowledge both the second common user 415 and the first commonuser 415 when the task is featured and presented to the featured user435.

Throughout the chat bidding session, the web site 310 may displayvarious statistics related to the chat bidding session. For example, andnot limitation, the web site 310 may display the total credits raisedduring the chat bidding session up to the current point in time, thetime elapsed in the bidding session, the number of posed tasks not yetpresented to the featured user 435, the name of the selected charity,the average time the featured user 435 has taken to act on or respond toeach presented task, and the estimated time remaining in the chatbidding session. At any point in time, the featured user 435 may pausethe chat bidding session and, thereby, pause any running clocks utilizedfor calculating statistics related to the chat bidding session.

FIG. 6 illustrates a flow diagram of a process 600 of a featured user435 initiating and participating in a chat bidding session, according toan exemplary embodiment of the chat bidding system 330 of the web site310.

As shown in FIG. 6, at 601, the featured user 435, such as a celebrity,may initiate the chat bidding session. This may occur when the featureduser 435 selects an appropriately labeled button, such as a buttonlabeled “Create StarChat.” At 602, a pop-up or dialog may appearallowing the featured user 435 to create the new chat bidding session.At 604, the featured user 435 may select a charity to benefit from thechat bidding session, and may determine a duration for the chat biddingsession. At 606 and 608, the networking system 300 may create the chatbidding session using the validated charity and duration selections.

Cache object validation may occur at 610. If a cache object does notexist, the networking system 300 may create a new cache object formanaging the chat bidding session. To improve performance, thenetworking system 300 may cache objects on the server assembly 230 sothat they can be used and manipulated quickly. Upon creation of a newchat bidding session, the networking system 300 may determine whether adialog for a chat bidding session has already been created. If not, at612, a chat bidding session dialog, in which tasks and responses may bedisplayed, is created and added to the cache. Then, the next time thedialog is requested, it may be retrieved from the cache. Upon creationof the new dialog, at 614, the networking system 300 may notify allonline users of creation of the chat bidding session.

A new chat icon may be created at 616, and may be viewable by the commonusers 415. At 618, the networking system 300 may direct the featureduser's web client 124 to a web page of the chat bidding session. At 620,the featured user's information, such as name and occupation, may beloaded into the chat bidding session for viewing by the common users415. At 622, the featured user 435 may await questions and tasks fromthe common users 415. While there are no new questions or tasks, asshown at 624, certain data about the chat may automatically update. Suchdata may include, without limitation, elapsed time, average time torespond to a question or task, and estimated time remaining. Preferably,this data is maintained and displayed as needed and appropriatethroughout the chat bidding session.

At 626, a process of acting on questions and other tasks of common users415 may begin. The networking system 300 may determine whether aquestion or task has already been chosen by the featured user 435 at628. At 630, if a question or task is already chosen, the question ortask is added to the tasks queue 420 in cache to be stored for efficientfuture use. At 632, the tasks queue 420 may be re-sorted based on bidvalues relating to one or more newly inserted tasks.

Returning to 628, alternatively, if a question or task has not yet beenchosen, a question or task may be retrieved, at 634, along with relateddata, such as data pertaining to the common user 415 who posed thequestion or task. At 636, the question or task data may be displayed sothat the featured user 435 may respond. At 638, a notification may besent to the common user 415 who posed the question or task, informingthe common user 415 that his question or task is the priority task. At640, this priority task may be removed from the tasks queue 420, and at642, the tasks queue 420 may be updated to reflect that the prioritytask has been removed.

FIGS. 7A-7B illustrate flow charts depicting further exemplary functions700 of the featured user 435 during the chat bidding session. At 701, ifthe featured user 435 previously elected a charity benefactor, thefeatured user 435 may change the selected charity from within the chatbidding session. Changing the charity may be initiated when the featureduser 435 selects a “Change Charity” button at 702. Then, a pop-up ordialog may appear, enabling the featured user 435 to select a newcharity. The pop-up or dialog may provide a list of approved charitiesfrom which the featured user 435 may choose. At 704, the featured user435 may select a new charity, and the newly selected charity may beverified at 707. This validation step may include, for example,verifying that the charity is a valid charity associated with thefeatured user 435. At 708, a notification of the new charity may betransmitted to all common users 415 related to the chat bidding session,and 710, all common users 415 and featured users 435 may be updated withthe newly selected charity.

In an exemplary embodiment of the present invention, changing thebenefiting charity of a chat bidding session may not affect adistribution of the revenues generated through the chat bidding sessionbefore the change occurred. In other words, a first charity may benefitfrom the chat bidding session for the time period during which suchfirst charity was specified as the benefiting charity. If the benefitingcharity is changed to a second charity during a chat bidding session,only revenues after the change may be generated for the benefit of thesecond charity.

At 712, the featured user 435 may have an ability to use the synchronousalert feature. This feature, as discussed above, may enable the featureduser 435 to send a message to all common users 415 participating in thechat bidding session. After selecting the synchronous alert feature,e.g. a “StarBlaster” button, at 712, a pop-up window may be presented tothe featured user 435 at 714. At 716, the featured user 435 may provideand submit a message for the common users 415. At 718, the message maybe transmitted to all common users 415 involved in the chat biddingsession.

As mentioned above, the featured user 435 may have an ability to selectthe duration of the chat bidding session. At 720, the featured user 435may change such duration. He or she may accomplish this by selecting a“Change Duration” button. At 722, a pop-up may appear, allowing thefeatured user 435 to modify the duration. At 724, the featured user 435may enter the modified duration information, which may then be validatedat 726. Upon approval of the new duration, a notification may be sent toall users in the chat bidding session at 728 and at 730. If the chatbidding session displays an end time to the common users 415, such endtime may be updated in accordance with the new duration.

As at 732 and 734, the featured user 435 may skip the priority questionor task. After the featured user 435 selects a “Skip Question” button at732, the question or task may be removed from the cache at 734. Then, anew priority task may be presented to the featured user 435.

At 736, the featured user 435 may opt to end pledging in the chatsession. For example, the featured user 435 may select a “SuspendPledges” button. This option may prevent common users 415 from posingadditional tasks, and may additionally prevent pledge increases forqueued tasks. At 738, the cache may be updated in response to thefeatured user's indication that pledges are no longer allowed, andaccordingly, the networking system 300 may no longer accept newquestions or tasks from the common users 415. Next, at 740 and 742, anotification may inform the common users 415 that no new questions ortasks may be posed in the chat bidding session. In an exemplaryembodiment of the chat bidding system 330, the featured user may berequired to continue acting on posed tasks until all tasks with non-zerobid values are acted upon. Common users 415 whose tasks remain in thetasks queue 420 after the featured user 435 exits the chat biddingsession may receive refunds for their pledged credits.

Turning to 744, an exemplary process of responding to a posed questionor task is depicted. After the question or task is answered at 746, aresponse is displayed via the chat bidding session. At 748, the questionor task may be removed from the cache, and at 750, the task and responsemay be stored in the cache as answered. At 752, the task and response,or question and answer, may also be stored in the database. Then, at754, notification of such response may be sent to the common users 415participating in the chat bidding session. At 756, common users 415 andfeatured users 435 may be informed that a response to the priority taskhas been issued, and the task and corresponding response may beavailable for viewing.

The featured user 435 may terminate the chat bidding session, such as byselecting an “End Chat” button at 760. After which, a notification maybe issued to the common users 415 in the chat bidding session at 762.The common users 415 may then receive notification that the chat hasended at 764. At 766, a record of the chat bidding session dialog may beremoved from the cache. At 768, all pledges associated with unansweredtasks may be voided when the chat bidding session ends at 770.

FIG. 8 illustrates an exemplary process 800 of a common user 415 joiningand viewing an exemplary chat bidding session. As shown in FIG. 8, at801, the common user 415 may elect to join a particular chat biddingsession. At 802, the server assembly 230 may redirect the common user415 to an appropriate web page for the chat bidding session, and thecommon user 415 may be added to a user list of the chat bidding sessionat 804. The common user 415 may then be presented with tasks to whichthe featured user 435 has previously responded in the chat dialog at806. Additionally, questions and tasks to which the featured user 435previously responded may appear in an “asked questions” area of the webpage at 808.

At 810, the networking system 300 may enter a cycle of updating ranks ofposed questions/tasks. Such updating may be necessary to ensure that thetasks, as displayed on the web site 310, may reflect accurate rankingsbased on updated bid values from common users 415. Updating may beimplemented, preferably behind the scenes and out of view of the users415 and 435, by providing a question selector on the client computer 102to iterate through questions and tasks in the local tasks queue 420.Each web client 124 may provide metadata to the server assembly 230describing changes to bid values and task ranks. At each iteration, at810, a web client 124 may determine whether the question selectorreferences an asked question/task. If so, at 812, an updated rank of thequestion or task may be retrieved from the tasks queue 420 on the serverassembly 230. The rank of the question or task referenced by thequestion selector may then be updated on the web client 124 to reflectcurrent bid values at 814.

FIG. 9 illustrates an exemplary process 900 of a common user 415participating in an exemplary chat bidding session. At 915, the commonuser 415 may use arrows, or similar selectors, to cycle through tasksand questions previously posed by that particular common user 415. At916, the networking system 300 may determine whether questions or tasksposed by other common users 415 exist in the queue 420. If no such otherquestions or tasks exist, the networking system 300 may clear areas ofthe cache used for displaying tasks and their pledges and ranks. Thecommon user 415 may then pose new questions or tasks to the featureduser 435. Alternatively, if one or more questions or tasks remain in thetasks queue 420, as at 920, data regarding such tasks may be retrievedfrom the cache and then displayed at 922. Then, when the common user 415enters a question or task at 924, the networking system 300 may insertsuch question or task into the tasks queue 420. If the newly posedquestion or task has not been previously posed in the chat biddingsession, the web page of the chat bidding session may then be updatedwith data regarding the newly posed question or task of the common user415. Otherwise, if the question or task was previously posed, the taskand related data, such as an associated bid value, may be retrieved fromthe cache at 932, and then displayed on the web page of the chat biddingsession at 934.

Preferably, the client computer 102, such as that used by the commonusers 415 or the featured user 435, and the server assembly 230 interactin the chat bidding session through a service executing a dynamicupdate. This service may enable the web page of the chat bidding sessionto update without user interactions, such as clicking a “Refresh” buttonon the web client 124. The dynamic update service may enable the commonuser 415 to view real-time positions of his tasks in the queue 420, aswell as real-time data for various other statistics viewable to thecommon user 415. The dynamic update service may enable the featured user435 to view real-time data related to, without limitation, any or all ofthe following: number of tasks in the tasks queue 420, number of queuedtasks associated with bids, elapsed time of the chat bidding session,estimated time to respond to all queued tasks, average time to respondto each task, amount of money raised, number of common users 415 viewingthe chat bidding session, and various other statistical data related tothe chat bidding session

Performance Bidding System

Through the performance bidding system 340, users may request to performon the web site 310, and may pledge credits to determine an order inwhich they may be allowed to perform. Such pledged credits may bedirected towards a benefiting charity or may be paid to the web site 310for the opportunity to perform. Alternatively, credits may be dividedbetween the web site 310 and the benefiting charity. In some exemplaryembodiments, the benefiting charity, if any, may be predetermined, andthe users may be notified of information regarding the charity.

The performance bidding system 340 may be available to both common users415 and featured users 435. For convenience, members of all classes ofusers may be referred to as “users.” Through the performance biddingsystem 340, common users 415 may have an opportunity to perform forfeatured users 435 and other common users 415. Similarly, featured users435 may have an opportunity to perform for common users 415 and otherfeatured users 435. Users participating in the performance biddingsystem 340, but not currently queued for a performance on the web site310, are herein referred to as observers. The users queued forperformances are herein referred to as performers. Together, performersand observers make up the participants of the performance bidding system340.

The performance bidding system 340 of the web site 310 performs in somemanners similar to the chat bidding session. Similarly to the chatbidding system 330, the performance bidding system 340 may comprise aqueue, specifically a performance queue, and a plurality ofparticipating users.

When a performance request reaches the top of a performance queue, theuser making the performance request may perform live for otherparticipants. During a performance, the networking system 300 mayprovide the performing user with music and lyrics, as in a karaoke styleperformance. If a non-karaoke type of performance is desired, the website 310 may provide other, appropriate support for the performance. Forexample, if the performing user indicates that she would like to performin spoken work, the web site 310 may provide soft background music asindicated by the performing user. The performing user may provide one ormore recording devices, such as a webcam and a microphone, and theserver assembly 230 may receive media representing the performance.Preferably, such media is streaming media. The web site 310 may presentthe performance, preferably streaming, to the observers.

Users who make performance requests may be provided with a menu ofselections for supporting their performance. For example, a userrequesting to perform karaoke-style may be presented with a list ofsongs for the web site 310 to provide music and lyrics. Upon selectingspecific performance support for a performance, the user's username andsupport selections, such as a song title, may appear in a status sectionof a web page of the performance bidding system 340 to identify theuser's position in the performance queue. All other queued performers,or alternatively, a predetermined number of highest ranked performers inthe performance queue, may also appear in the status section, therebyproviding participants with data regarding expected performances.

Through the performance bidding system 340, the web site 310 may displaydata regarding the performers, observers, or all participants. Forexample, and not limitation, the web site 310 may display the totalnumbers of performers and observers. The web site 310 may also displaystatistics of performers or of the total participating users, such asdisplaying geographic statistics of the performers or of allparticipants. This may give participants an estimate of the geographicrange of the performers, and may give performers a geographic range ofthe observers.

Upon making a performance request, a user may pledge credits to therequest and, thereby, associate the request with a bid value. If no bidvalue is provided with a performance request, the request may be placedat the bottom of the performance queue. However, a performer mayincrease her position in the queue by increasing her pledge value aboveother another performer's pledge value. Performers may rise in theperformance queue as others perform and are, consequently removed fromthe queue. A performer's position in the queue may be dynamic, as allperformers may increase their bid values to escalate their own positionsin the performance queue. Therefore, a performer's queue position mayperiodically change and be updated accordingly in the status section.

A bidding dialog box on the web site 310 may provide performers withmeans to increase their pledges and, thereby, potentially increase theirpositions in the performance queue. The bidding dialog box may displayto each performer an amount of credits required to increase theperformer's queue position to a certain rank in the performance queue.After a performer attains one of the top X positions in the performancequeue, the performer's position may become locked. Locking the top Xpositions in the performance queue may be implemented in variousmanners, including those described above with reference to the top Npositions of the tasks queue 420. Performers with the top X lockedpositions may be able to perform in succession regardless of pledgeincreases of participants. At a point in time, the top X performers,along with their support selections, may be displayed in the statussection of the web page of the performance bidding system 340.

While a user is performing on the web site 310, data from her profilemay be displayed to participants of the performance bidding system 340.Participants may also have an opportunity to follow a web hyperlink and,thereby, view the performing user's full profile on the web site 310.Participants may then be able to learn more about the performing userand may leave feedback on the performing user's profile.

At the end of each performance, a rating window may automatically bepresented to the participants. Through the rating window, theparticipants may rate the performance or leave feedback regarding theperformance. Top-rated performances may be stored on the server assembly230 and accessible for replay by each participant.

FIG. 10 illustrates a flow diagram of an operation 1000 of theperformance bidding system 340, according to an exemplary embodiment ofthe networking system 300. As shown in FIG. 10, at 1002, a participantmay enter a lobby, or introductory web page, of the performance biddingsystem 340 of the web site 310. The participant may participatepassively by requesting, receiving, and viewing streaming media of thecurrent performing user at 1004. The participant may elect to become aperformer at 1006. At 1008, the participant may be presented with aselection of support material, such as a list of songs from which theparticipant may select a song to perform karaoke-style. After theparticipant selects support material, the user's username and supportmaterial may be inserted into the last position of the performancequeue, at 1010, if no credits are yet pledged. The performance queue maybe maintained and dynamically updated at 1012. At 1014, the participantmay be offered an option to pledge credits, or additional credits, toescalate her position in the performance queue. If the participant bidscredits to escalate her position, at 1016, the networking system 300 maydetermine whether the bid is sufficient to raise the participant'sposition in the performance queue. If the bid is sufficient, the process1000 returns to 1012 and updates the performance queue.

When a performance ends at 1020, a next performer in the performancequeue may be alerted. Additionally, the queue may be updated, and arating dialog box may be displayed at 1022, providing participants anopportunity to rate the previous performer and to provide comments aboutthe performance. Accordingly, participants, including the previousperformer, may be provided with instant feedback from otherparticipants. Viewing participants may complete a rating form in thedialog box or may bypass completing the rating form at 1028.

When a participant performs, streaming media, such as audio and video,of the performer may be presented to all viewing participants at 1024.If the participant is performing karaoke-style, the participant may beprovided with background music and lyrics at 1026.

Accordingly, users of the networking system 300 may interact with oneanother by performing for one another, viewing such performances, andcommunicating regarding such performances.

Telephony Switching System

In accordance with an exemplary embodiment of the telephony switchingsystem 350, parties may contact one another anonymously. The telephonyswitching system 350 may enable a party to limit calls from certainusers and groups of users, and according to predefined schedules. Thisfeature of the web site 310 may be especially beneficial for featuredusers 435. Through the telephony switching system 350, a featured user435 may place or accept a call to or from a common user 415 whilemaintaining a concealed phone number. Additionally, through predefinedscheduling rules, the featured user 435 may block all calls duringcertain time periods. Furthermore, common users 415 may transition achat session to a telephone call without compromising the privacy commonto chat sessions.

In an exemplary embodiment of the networking system 300, a calling partymay request a connection, such as a telephone chat, to a receivingparty. Prior to attempting to forge the connection, the networkingsystem 300 may verify that the receiving party is willing to accept theconnection from the calling party. Once verified, the networking system300 may place a call to each of the calling party and the receivingparty, and may then patch the two calls together so that each of the twoparties can engage in a chat without divulging contact information, suchas a telephone number, to the other party. Alternatively, the callingparty may initialize the connection by contacting a service center andrequesting to be connected to the receiving party via a communicationdevice. In such an embodiment, the service center may initiate a call tothe receiving party and patch that call to the calling party.

Before a user may utilize the telephony switching system 350, acommunication device of the user may need to be registered with thetelephony switching system 350. FIG. 11A illustrates a process 1100 ofregistering a communication device with the telephony switching system350. As shown in FIG. 11A, at 1101, the user of the telephony switchingsystem 350 may request that the communication device be registered. At1102, the telephony switching system 350 may register the communicationdevice on a database of the server assembly 230. At 1104, the telephonyswitching system 350 may create a unique identifier associated with thecommunication device. At 1106, a message may be displayed on the website 310 notifying the user of the unique identifier and itsavailability for use. At 1108, the user may either assign his ownpersonal identification number (“PIN”) or request that the telephonyswitching system 350 create a PIN for the user. At 1110, telephonyswitching system 350 may determine whether the system 350 is to create aPIN or, alternately, whether the user has submitted a PIN forvalidation. If the telephony switching system 350 was asked to assign aPIN, such a PIN is created and assigned by the telephony switchingsystem 350 at 418. Otherwise, the user assigned PIN may be validated. At412 and 420, the web site 310 may display that the PIN is active andready for use.

Accordingly, after completing the registration process, thecommunication device may be associated with a unique identifier and aPIN. Generally, the unique identifier may be used to identify a callingparty when a connection is requested via the telephony switching system350. The PIN, on the other hand, may be used to identify a receivingparty. In other words, when attempting a connection, the calling partymay provide a unique identifier to identify himself, and may provide aPIN to identify the receiving party. Accordingly, the calling party maybe required to receive a PIN from the receiving party before connectingto the receiving party. Each receiving party may request and receivemultiple PINs from the telephony switching system 350. According towishes of the receiving party, each PIN may serve a distinct purpose.For example, a first PIN may be distributed to family members forcontacting the receiving party, and a second PIN may be distributed tobusiness associates for contacting the receiving party. This will bedescribed in further detail below.

FIGS. 11B-11C illustrate block diagrams of exemplary embodiments of thetelephony switching system 350. As shown in FIG. 11B, an exemplaryembodiment of the telephony switching system 350 may generally compriseat least two communication devices 1130, a service center 1160, and atelephony switch 1170.

As shown in FIG. 11B, the calling party 1180 may use the firstcommunication device 1140 to communicate with the service center 1160.The service center 1160 may be in communication with the telephonyswitch 1170. The telephony switch 1170 may be in communication with thefirst communication device 1140 and the second communication device1150, and may connect the first communication device 1140 to the secondcommunication device 1150. For purposes of FIGS. 11B-11C, thecommunication devices 1130 are already registered with the telephonyswitching system 350.

The communication devices 1130 may include a first communication device1140 and a second communication device 1150. For purposes of anexemplary embodiment of the telephony switching system 350,communication devices 1130 may comprise various devices capable ofcommunicating over a communications network, such as a telephone networkor the internet. Each communication device 1130 may be a wiredtelephone, wireless telephone, cellular telephone, satellite telephone,voice over IP (“VoIP”) phone, PDA, soft phone, computer, or other devicecapable of audio and/or video communications. The first communicationdevice 1140 may be associated with a first phone number and a callingparty 1180. The first phone number identifies the first communicationdevice 1140. Similarly, the second communication device 1150 isassociated with a second phone number and a receiving party 1190. Thesecond phone number identifies the second communication device 1150.

The service center 1160 may comprise one or more hardware or softwaredevices, or various combinations thereof, capable of receiving andstoring registrations relating to communication devices 1130, managingsuch registrations, analyzing connection requests relating to registeredcommunication devices 1130, and initiating and managing connections.

The telephony switch 1170 may comprise various telephone exchanges,switches, or combinations thereof. For example, and not limitation, thetelephony switch 1170 may be a private branch exchange (“PBX”). Thetelephony switch 1170 may connect the calling party 1180 to thereceiving party 1190 if such a connection is deemed allowed.

In an exemplary embodiment of the telephony switching system 350, thetelephony switch 1170 may comprise one or more PBX switches trunked toother telephony switches and telephony service centers with various PBXslocated around the world. Trunks may allow multiple calls to be combinedinto a single channel and be delivered to other PBXs either in the sametelephony switch 1170 or other telephony switches having availablechannels to VoIP termination providers or public switched telephonenetwork (“PSTN”) terminations. In addition, the telephony switch 1170may provide trunks and termination end points to provide high qualityand low cost termination to communication devices 1130. The terminationend points and trunks may also be provided through a third party VoIPtermination or PSTN. In an exemplary embodiment, the PBX implementationmay be a software system allowing existing telephony infrastructure tointeract using VoIP standards.

In some exemplary embodiments of the telephony switching system 350, theservice center 1160 and the telephony switch 1170 may be integratedtogether. For example, the service center 1160 may comprise a PBX forproviding the call-handling for users requesting communications withother users. Calls may traverse digital circuits, analog interfaces,VoIP networks, or various other networks for delivering communications.Digital circuits may be defined telephony standards, such as T1 linescarrying 24 channels of voice to standard telephony companies. Analoginterfaces may provide single channels of voice for delivery to thepublic switched telephone network (PSTN). VoIP protocols, such as SIP,IAX, H.323, and others, may enable audio, metadata, and video to bedigitized, secured, and compressed for delivery over computer networksto other service centers or other termination endpoints. These deliverymediums may enable the PBX in the service center 1160 to connect two ormore parties anonymously.

FIG. 12 is a flow diagram illustrating a method 1200 of handling aconnection request from the calling party 1180 to connect to thereceiving party 1190, according to an exemplary embodiment of thetelephony switching system 350. At 1210, the service center 1160receives a connection request from the calling party 1180 to connect tothe receiving party 1190. Such communication request may be made by thecalling party 1180 through the first communication device 1140.Alternatively, the communication request may be made by the callingparty 1180 via a web interface. At 1220, the service center 1160 maydetermine whether a connection is allowed given predetermined variables.Such variables may include certain contact rules preset by the receivingparty 1190. For example, and not limitation, each user may provide alist of users permitted to call, a list of users not permitted to call,times when calls are allowed, or other suitable calling criteria. If theconnection request is not allowed, the service center 1160 may notifythe calling party 1180 of the denial, as at 1230. Otherwise, if theconnection request is approved, at 1240, the service center 1160 mayforward the connection request to the telephony switch 1170. At 1250,the telephony switch 1170 may connect to the second communication device1150 and, therefore, to the receiving party 1190 using the secondcommunication device 1150. Finally, at 1260, the telephony switch 1170may patch together its connections to the calling party 1180 and thereceiving party 1190, such that the two parties 1180 and 1190 are incommunication with each other. If the receiving party 1170 does notanswer, the calling party 1160 may be permitted to leave a voice messagewithin the receiving party's video/voice mailbox.

Referring now back to FIG. 11B, communication devices 1130, such as thefirst and second communication devices 1140 and 1150, may be registeredwith the service center 1160. Registrations may be communicated to theservice center 1160 through various manners. For example, and notlimitation, registration of the first communication device 1140 may becommunicated to the service center 1160 through a phone call, such as bythe calling party 1180 calling the service center 1160 and providingregistration information.

Alternatively, registration may be accepted through a web client 124.The web client 124 may receive registration information and send it tothe server assembly 230. The server assembly 230 may be part of, or incommunication with, the service center 1160. Alternatively, the servicecenter 1160 may be part of the server assembly 230. The server assembly230 may provide the registration information to the service center 1160.Registration information for a communication device 1130 may include,without limitation, a phone number associated with the communicationdevice 1130, an account identifier, and a set of contact rules.

The account identifier may comprise information for identifying a useraccount on the web site 310. The specified user account may then beassociated with the communication device 1130. As discussed above, anaccount user, such as the calling party 1180, may have a credit accountassociated with the user account. The credit account may track a numberof credits available to the associated user for purchasing services fromthe web site 310. By associating the user account with the communicationdevice 1130, credits available to the user of the user account may alsobecome available for the purpose of purchasing connections through thetelephony switching system 350. Additionally, credits may be charged forthe duration of connections initiated through the telephony switchingsystem 350.

As a part of a registration, the set of contact rules may indicate whomay connect to the communication device 1130, and when such connectionsmay occur. Various rule types may be included in the contact rules. Forexample, and not limitation, the contact rules for the receiving party1190 or the second communication device 1150 may specify thatconnections may be made from the first communication device 1140 onlyduring certain hours. For purposes of establishing contact rules, thereceiving party 1190 may refer to the first communication device 1140by, for example, its associated phone number, its unique identifier, ora username or other alias of the receiving party 1190. For additionalexample, the contact rules may specify that users of a predefined groupmay not connect to the second communication device 1150, or that usersof the predefined group may connect to the second communication device1150 only during specified hours. The contact rules may specify that thefirst communication device 1140, or users of the predefined group, maynever connect to the second communication device 1150 or, alternatively,may connect to the second communication device 1150 at any time. Thecontact rules may also specify categories of allowed or disallowedcalls, such as conference calls, faxes, or calls from cellulartelephones. One skilled in the art will recognize that the contact rulesmay specify alternate handling of connection requests based on variousfactors, including, without limitation, subject matter of the call,gender of the calling party, geographic location of the calling party,and/or time of the call.

At least partially because of the wide range of potential contact rules,embodiments of the telephony switching system 350 may have wideapplication. For example, the telephony switching system 350 may be usedfor recruiting and screening employment opportunities. A potential hireemay structure contact rules around acceptable employment opportunities.For further example, the potential hiree may allow calls only fromrecruiters or employers having job opportunities in a predefinedgeographic area, with salaries over a predetermined threshold, and/orwith a predetermined set of benefits.

The contact rules may specify actions to be taken if a connection isrequested when the receiving party 1190 is unavailable and cannot,therefore, respond to a connection made through the telephony switchingsystem 350. For example, and not limitation, the contact rules mayspecify which parties are approved to leave messages, and which partiesare to be presented with a pre-recorded message from the receiving party1190. Further, the contact rules may specify alternate voicemailrecordings to be presented to alternate calling parties 1180. Aconnection may be automatically terminated if the calling party 1180 isnot approved to leave a message or to receive a pre-recorded messagewhen the receiving party 1190 is unavailable. Additionally, if a call isattempted, but the receiving party 1190 does not answer the call, thesystem 350 may terminate the call when the system 350 detects that thereceiving party's voicemail is answering the call. Such termination maybe useful in maintaining the privacy of the receiving party 1190 becausepersonal information, such as the person's identity or phone number, maybe present on the standard voicemail greeting. In such cases, thecalling party 1180 may be diverted to the receiving party's mailboxassociated with the system 350, or the call may be terminated withoutallowing a message to be left.

Mailboxes on the system 350 may receive messages of various types. Forexample, and not limitation, such mailboxes may include conventionalvoice mailboxes, video mailboxes, audio mailboxes, email mailboxes, andmultimedia mailboxes capable of receiving various types of mail. When acall to the receiving party 1190 is unanswered, the calling party 1180may be redirected to a voice mailbox, or may receive instructions forleaving a message in some other media format. Through the web site 310or over a phone call, the receiving party 1190 may have various optionsfor organizing, sorting, retrieving, and responding to messages,including those messages left through the telephony switching system350. For example, the receiving party 1190 may sort messages based oncharacteristics of senders of the messages, or on other characteristicsof the messages. The receiving party 1190 may respond individually or enmasse to all messages or a set of messages. Such response may also takevarious media formats, such as video, audio, email, or multimedia.

In addition to the above, the contact rules may specify that any personwho provides a specific PIN may connect to the second communicationdevice 1150 according to a predefined schedule associated with thecaller PIN. As described above, the receiving party may have multiplePINs for distinct purposes. Multiple caller PINs may be assigned andused for various users, groups, or call types. For example, differentcaller PINs may be provided for chat sessions, for a family group, andfor a celebrity fan group. Each caller PIN may be automaticallygenerated by the service center 1160, or the receiving party 1190 maycreate the caller PIN and provide such caller PIN to the service center1160. Each caller PIN may, for example, allow unlimited uses, a specificnumber of uses, or may be given an absolute or relative terminationdate.

Connections may be requested in various ways. For example, the callingparty 1180 may call the service center 1160, which is preferablyidentified by a toll free number. When connected to the service center1160, the calling party 1180 may provide information to identify thereceiving party 1190. For example, and not limitation, the calling party1180 may enter a username for a user account of the receiving party1190, an identifying PIN associated with the receiving party 1190, theunique identifier of the receiving party 1190, or various otheridentifiers or aliases of the receiving party 1190. Preferably, theservice center 1160 receives such information from the calling party1180 via an automated service provided by the service center 1160.

If the receiving party's contact rules dictate that the calling party1180 provide a caller PIN, the calling party 1180 may be prompted toprovide such a caller PIN. In a first exemplary embodiment, the servicecenter 1160 may automatically recall the unique identifier of the firstcommunication device 1140. In an alternate exemplary embodiment, theservice center 1160 may prompt the calling party 1180 to enter theunique identifier of the first communication device 1140. The servicecenter 1160 may consider this unique identifier when determining whetherto approve the connection. After receiving the connection request, theservice center 1160 may approve or deny the connection based on datareceived from the calling party 1180 and the first communication device1140, as compared to the contact rules of the receiving party 1190.

As illustrated in FIG. 11C, and as briefly discussed above, theconnection request may also be made over the internet through use of oneor more web clients 124. Through a first web client 124, the callingparty 1180 may be logged into a user account on the web site 310.Through links in the web site 310, the calling party 1180 may request aconnection to the receiving party 1190. The calling party 1180 may notbe required to know the name or phone number of the receiving party1190, so long as the calling party 1180 can provide predeterminedidentifying information regarding the receiving party 1190. For example,and not limitation, the calling party 1180 may provide or select ausername of a user account associated with the receiving party 1190. Theserver assembly 230 may receive the connection request and may route therequest to the service center 1160 for approval. The service center 1160may approve or deny the connection based on contact rules of thereceiving party 1190.

Alternatively, the receiving party 1190 may be logged onto the web site310 when the calling party 1180 requests a connection to the receivingparty 1190. In that case, the receiving party 1190 may be notified ofthe connection request via a second web client 124 used by the receivingparty 1190. Via the second web client 124, the receiving party 1190 mayapprove or deny the connection request. The receiving party's approvalor denial may be received by the server assembly 230. If the receivingparty 1190 approves or denies the connection request via the second webclient 124, the service center 1160 need not determine whether toconnect the calling party 1180 to the receiving party 1190. If thereceiving party 1190 approves the connection, the server assembly 230may notify the telephony switch 1170 of such approval. The telephonyswitch 1170 may then connect the calling party 1180 to the receivingparty 1190, as described further below.

The service center 1160 may receive connection requests from the serverassembly 230 or from the calling party 1180. In response to suchreceipt, the service center 1160 may determine whether to honorconnection requests. After receiving the connection request of thecalling party 1180, the service center 1160 may query the contact rulesof the receiving party 1190 to determine whether the calling party 1180may connect to the receiving party 1190. If the contact rules specifythat the calling party 1180 or the first communication device 1140 mayconnect to the receiving party 1990 or the second communication device1150 at the time the connection request is made, then the service center1160 may approve the connection request. Otherwise, the service center1160 may deny the connection request. If the receiving party 1190 islogged into the website and approves the connection, the contact rulesverification step may be skipped.

If a connection request is denied, the calling party 1180 may bedisconnected from the service center 1160 without being connected to thereceiving party 1190. Preferably, such a disconnection is preceded bythe service center's providing a polite message to the calling party1180 notifying the calling party 1180 that the requested connection isnot allowed. If the connection request was made via the first web client124, then the server assembly 230 may prompt the first web client 124 tonotify the calling party 1180 of the denial.

If, on the other hand, the connection request is approved, the servicecenter 1160 may communicate the approved connection request to thetelephony switch 1170. The telephony switch 1170 may then connect thecalling party 1180 to the receiving party 1190. For example, and notlimitation, the telephony switch 1170 may direct a signal to the secondcommunication device 1150 indicating that a connection is requested.Such a signal may result in the second communication device 1150 issuingan alert, such as an audible tone, to notify the receiving party 1190that a call is waiting. Caller identification data associated with theservice center 1160 may also be transmitted to the second communicationdevice 1150. Accordingly, if the second communication device 1150 iscapable of displaying caller identification data, it may display datarelated to the service center 1160. If the second communication device1150 is activated after receiving the signal, such as by the receivingparty 1190 answering a phone call, the telephony switch 1170 may connectthe first communication device 1140 to the second communication 1150device. Upon activation of the second communication device 1150, thetelephony switch 1170 may immediately connect the first and secondcommunication devices 1140 and 1150. Alternatively, the service center1160 or the telephony switch 1170 may prompt the receiving party 1190 toaccept the connection. Then, the call may be connected only if thereceiving party 1190 accepts the connection.

If an approved connection request was received via the first web client124, then the telephony switch 1170 may send signals to both the firstcommunication device 1140 and the second communication device 1150.Caller identification data associated with the service center 1160 maybe transmitted to the first and second communication devices 1140 and1150. Accordingly, if the communication devices 1140 and 1150 arecapable of displaying caller identification data, they may display datarelated to the service center 1160. In response to such signals, thecommunication devices 1140 and 1150 may issue alerts to the calling andreceiving parties 1180 and 1190 of the connection. When the calling andreceiving parties 1180 and 1190 activate the first and secondcommunication devices 1140 and 1150, the two parties 1180 and 1190 maybe connected.

In an exemplary embodiment of the telephony switching system 350, thecaller identification information may include data relating to theservice center 1160, such as a phone number of the service center 1160.In an alternative embodiment, calls may be associated with alternativecaller identification information. For example, and not limitation, thecaller identification information may include an alias, username, orhandle of the other party and/or a telephone number associated with theweb site 310 or service center 1160.

In an exemplary embodiment of the telephony switching system 350, atleast one of the calling party 1180 and the receiving party 1190 may berequired to use credits to purchase the connection request, the approvedconnection, or both. Additionally, call crediting may be required foreach unit or other measurement unit of call time. Credits may beautomatically debited from applicable accounts when a connection isrequested or when a call is connected.

The cost, in credits, of connection requests and connections may varybased on predetermined variables. For example, connection to a faxmachine may require more credits than connection to a landlinetelephone. A connection during a business day may require more creditsthan a connection on an evening or weekend. When the calling party 1180requests a connection to the receiving party 1190, the calling party'scredit account may be debited for the request. If the receiving party1190 accepts the connection, through contact rules or through anaffirmative approval, credit accounts of both parties 1180 and 1190 maybe debited for the connection. Alternatively, a debit may only berequired for approved connections instead of for connection requests aswell, or a debit may only be required for the calling party 1180.Additionally, in some exemplary embodiments of the telephony switchingsystem 350, a debit may only be required from the calling party 1180when a common user 415 connects to, or requests a connection to, afeature user 435.

Media Interaction System

The networking system 300 may further comprise a media interactionsystem 360 accessible through the web site 310. The media interactionsystem 360 may enable a first user to interact with a second userthrough a use of one or more media objects.

Media objects may allow users a creative and personal means to interactwith other users. Media objects may comprise various types of media,such as computer animations, other video, audio, or text. Preferably, amedia object may comprise an animation in conjunction with anillustration package capable of superimposing a user's existing displayobjects. An animation in the media object may be implemented in variousformats, such as Flash™, Microsoft Silverlight™, or the like. Whendisplayed, the media object may have a transparent background. In otherwords, media objects of the networking system 300 may appear to float infront of other objects displayed on a client computer 102.

Media objects may comprise web-based objects selectable by the firstuser and sent to the second user after prompting by the first user. Thefirst user may select a media object from a predetermined collection ofmedia objects presented to the first user. The media objects may beassociated with a theme, such as a particular holiday, feeling, orseason. Media objects available for selection on the web site 310 maychange or rotate based on various factors, such as season or politicalclimate.

Media objects may be dynamic and customizable to further personalizeinteractions between the first user and the second user. For example,and not limitation, a username of the first user may be automaticallyinserted into a media object sent to the second user, or the networkingsystem 300 may prompt the first user for text to insert into the mediaobject. For further example, the media object may comprise apersonalized note to the second user. After the first user selects anoption to send the personalized note, the first user may be prompted toenter custom text to be displayed in the note. When the second userreceives the note, an animation may play in the web client 124 of thesecond user. The animation may display, for example, a pen writing thetext entered by the first user.

When a media object is selected for sending, the selected media objectand any user customizations may be stored and queued on the serverassembly 230. To efficiently utilize space on the server assembly 230,if a media object includes an animation, the media object may preferablycomprise no more than approximately 30 seconds of animation at 30 framesper second. Additionally, the file size of a media object is preferablyno more than approximately 150 kilobytes. Those of skill in the art willrecognize that these exemplary animation characteristics and file sizeare provided as sample characteristics for use in an exemplary computersystem. As computing technology improves, these characteristics may bebroadened.

When the first user selects a media object to send to the second user,the chosen media object may be stored in a queue of the server assembly230. In an exemplary embodiment, display of the packaged media object onthe second user's client computer 102 may be purposely delayed until apredetermined event occurs. For example, such display may be delayeduntil the second user returns to a chat room in which the second useractively chats with the first user.

In an exemplary embodiment of the media interaction system 360, themedia object may be delivered to the second user's client computer 102through a pull method. The pull method may be implemented by creating apulse, or heartbeat, that is repetitively fired by the web client 124,and may be received by the server assembly 230. The request may informthe server assembly 230 of a current state of the web client 124 and anyevents that should be handled. In return for each pulse sent by the webclient 124, data is delivered to the web client 124 regarding how tohandle such events.

The first user's request to send the media object may be transmitted tothe server assembly 230 in this manner, and may create an event andaccompanying metadata on the server assembly 230. The server assembly230 may read the metadata to determine how to handle the event. Based onthe metadata, the server assembly 230 may determine that the event is amedia object and should be addressed to the second user's clientcomputer 102. The server assembly 230 may then create an event andmetadata for the second user's web client 124, and may retain the eventand metadata in a queue until the server assembly 230 hears from thesecond user's web client 124. When the second user's web client 124fires a pulse, the server assembly 230 may respond by transmitting thedata in its queue, such as the event related to the media object, to theweb client 124. The web client 124 may then receive the data in thequeue, including the media object event. After the event is received,the second user's web client 124 may display the media object selectedby the first user.

In an alternative exemplary embodiment, in which a communicationschannel is enabled between the second user's web client 124 and theserver assembly 230, the media object may be delivered to the seconduser's client computer 102 via a push method. In that case, the serverassembly 230 may remain aware of the web client 124 because of the openchannel and, therefore, the web client 124 may remain available torespond to requests sent by the server assembly 230. The server assembly230 may send the event and associated metadata directly to the seconduser's web client 124 without the web client 124 firing a pulse todetermine whether it should receive the media object.

The networking system 300 may provide three categories of media objects,including packaged media objects, extended media objects, andbi-directional media objects.

A packaged media object may comprise a flash animation allowing littleto no selectable customization by the first user. In other words, thepackaged media object may be pre-packaged and sent as-is. The packagedmedia object may be an animation, such as a flash animation, which mayinclude a catch phrase or punch line.

A packaged media object may be selected for delivery from variousportions and web pages of the web site 310. Preferably, however, thefirst user may select and send a packaged media object from within achat session with the second user. During the chat session, there may bea portion of the chat web page comprising a menu of sendable packagedmedia objects. The menu may represent each packaged media object as anicon, which may or may not be animated. For example, the web site 310may provide a drop-down menu of selectable media objects. When the firstuser places a cursor over a menu item for a particular packaged mediaobject, a pop-up may identify a name or description of the packagedmedia object.

When the first user clicks a list item representing a chosen packagedmedia object, the packaged media object may be delivered to the seconduser. In some embodiments of the networking system 300, before thepackaged media object is sent, the first user may be asked to confirmthat he wants to send the packaged media object. But this is notrequired. The networking system 300 may display the media object on theclient computers 102 of both the first user and the second user. Forexample, if the media object comprises a flash animation, the flashanimation may be played on each of the client computers 102.

Extended media objects may comprise interactable flash animations fromthe first user to the second user. For example, and not limitation, anextended media object may be a virtual gift, such as a locket containingan image selected by the first user. Alternatively, an extended mediaobject may contain virtual food or a virtual beverage. In an exemplaryembodiment of the networking system 300, the first user may select theextended media object from a virtual gift shop on the web site 310. Theextended media object may then be displayed to the second user withoutaffirmative prompting of the second user or, alternatively, the extendedmedia object may be delivered to a virtual mail box or other virtuallocation of the second user. In the latter case, the second user may berequired to retrieve the extended media object from its virtuallocation.

A difference between a packaged media object and an extended mediaobject may be that, before a chosen extended media object is sent, thefirst user may be prompted to provide some degree of customization forthe extended media object. For example, the first user may be asked toselect a specific gift or beverage for the second user. As a result,unlike with a packaged media object, the first user may observe adifferent display of the media object than observed by the second user.For example, while the first user may view a virtual bar for selecting adrink to send the second user, the second user may view a prepareddrink.

A bi-directional media object may allow, or require, interaction fromboth the first user and the second user. For example, and notlimitation, the bi-directional media object may comprise a game for twoor more players. The first user may initiate the bi-directional mediaobject from, for example, a profile of the second user. Alternatively,the first user may choose to send a bi-directional media object and maythen be prompted to select a recipient user, such as the second user, toreceive the bi-directional media object. After the first user initiatesthe bi-directional media object, a prompt or invitation may be sent tothe second user, requesting that the second user participate in thebi-directional media object.

During interaction within a bi-directional media object, the first usermay dictate an action and may receive a response from the second user.This may occur iteratively in a bi-directional media object constitutingan ongoing game. Selected action of the first and second users within abi-directional media object may be stored in a shared object within aflash animation file.

Two or more users may participate in a bi-directional media object. Whenusers, such as the first and second users, participate in abi-directional media object, their web clients 124 may become staticallylinked through a dedicated server object providing a dedicatedcommunications channel. This may provide an efficient delivery mechanismfor the users.

The media object may be cached on the client computers 102 of the firstand second users. In a first exemplary embodiment of the mediainteraction system 360, an HTTP protocol is provided for implementing apull method for bi-directional media objects. The pull method may besimilar to that described above for other media objects. With thebi-directional media object, however, the pulse from each involved webclient 124 requests that the server assembly 230 act as a proxy, andthat the data being transmitted from the web client 124 should beaddressed to the dedicated server object associated with thebi-directional media object. In the pulse, the web client 124 may alsorequest that the server assembly 230 transmit event data relating to thebi-directional media object, such as actions of other usersparticipating in the bi-directional media object.

In another exemplary embodiment, when a communications channel isenabled between the web client 124 and the server assembly 230, a pushmethod may be implemented similar to the push method described above. Inthat case, the web client 124 may have direct access to the dedicatedserver object, which may send events and metadata for the bi-directionalmedia object directly to the involved web clients 124.

Because the bi-directional media object may require interaction fromboth the first and second users, it may be required that both users belogged into the web site 310 during use of the bi-directional mediaobject.

When a bi-directional media object is complete, such as when a game hascome to its conclusion, either of the users may choose to run thebi-directional media object again. In that case, the other user mayreceive a prompt requesting whether to replay the bi-directional mediaobject. If the user and the second user agree to replay thebi-directional media object, the bi-directional media object may berestarted. Results of the bi-directional media object, such as who won agame in the bi-directional media object and statistics of the game, maybe stored in a database on the server assembly 230 for future use.

FIG. 13 illustrates a flow diagram of an operation 1300 of abi-directional media object, according to an exemplary embodiment of themedia interaction system 360. At 1301, a web client 124 may begin toplay the bi-directional media object. At 1305 and 1310, the first usermay send a request to the second user requesting participation in thebi-directional media object. At 1315, the second user may agree orrefuse to participate. If the second user refuses, a rejection may bedisplayed to the first user at 1345, and the bi-directional media objectmay terminate at 1350. Otherwise, if the second user agrees toparticipate, the bi-directional media object may be displayed on the webclients 124 of both users at 1320. At 1325, a cycle may begin of thefirst and second users taking turns interacting with the bi-directionalmedia object. In a first iteration of the cycle, the first user mayinteract with the bi-directional media object at 1325. Interaction datamay be transmitted to the server assembly 230 at 1330, and may betransmitted to the second user at 1335. At 1340, the results of thefirst user's interaction may be displayed on the web clients 124 of thefirst and second users. Then, the cycle may repeat at 1325, with thesecond user interacting with the bi-directional media object.

Accordingly, the media interaction system 360 may enable users tointeract with one another through multimedia content displayed on theweb site 310.

Display System

The display system 370 of the web site 310 may provide a means to modifya look and feel of the web site 310 as presented to the user via the webclient 124. Predetermined elements of the visual look and data contentof the web site 310 may be user-adjustable. The data presented to theuser can be customized by changing the colors and layout of website dataelement containers. Also, the website data presented can be filtered bythe user's theme preference.

User configurations may be stored in a web cookie on the client computer102, and in a database field unique to each individual user's profile.Web cookies provide a standard means for the web client 124 to maintainits state within a given internet domain. Accordingly, future visits tothe web site 310 may not require the web client 124 to download datarelating to the theme, color, or display defaults for the user. The webcookie may remain on the client computer 102 even after the web client124 is closed. If the user logs into the web site 310 and the web client124 is unable to find a web cookie on the client computer 102, the webclient 124 may then retrieve default theme, color, and display value,and may create a web cookie for future use.

When the user logs onto the web site 310, an access token is generatedfor the user. A new access token may be generated each time a user isauthenticated and logs into the web site 310. The access may be providedto the server assembly 230 when the web client 124 interacts with theserver assembly 230. The access token may enable the server assembly 230to uniquely identify the web client 124. The access token may have alimited lifespan and may be regenerated at each login. The access tokenmay be stored in web cookies and in a cache object. While the user islogged into the web site 310, the user's configurations may be stored inthe cache object in addition to being stored in the database.

If the user has not selected a preferred theme or color in their website preferences, a default theme and color may be used. Defaultconfigurations may be based on certain data relating to the user. Suchdata determining the default configuration may include, withoutlimitation, the user's member category (i.e., common or featured),gender, or specified purpose for using the web site 310. The web sitemanager 315 may modify available themes and color schemes periodically,or at any time. Users may be able to change a displayed color schemewith a single mouse click. This may be made possible by switchingcascading style sheets (“CSS”) and page graphics of the web site 310through an object-oriented language and dynamic updates.

Page graphics and text may be altered for a variety of needs. Suchalteration may be implemented by using compartmentalization, or ahierarchy, for art and text for presentation to the user via the webclient 124. For example, distinct folders may be provided for site,theme, and sub-theme. Each folder may include, for example, a color anda language. Further, each color for site, theme, and sub-theme mayinclude its own language folder.

By breaking the site into these compartments, a change of folderreference for each CSS, graphic, or text object may dynamically changecolors, themes, and languages without requiring reloading of a web pageon the web site 310. This implementation may also simplify developmentof the web site 310, as background code need not define themes,sub-themes, languages, or colors. New themes, colors, languages, andvarious other configuration details may be provided without anyadditional code.

When the user changes his or her color preference, the change is storedin the current session's cache object and in the user's local webcookie. The user's login session on the web site 310 may expire from thecache object after the web site 310 is unloaded from the web client 124.Removal of the cache object on the server assembly 230 may occur byvarious means. In an exemplary embodiment of the display system 370, theweb client 124 may send a log-off request to the server assembly 230. Inthe event this signal is not received, the server assembly 230 mayrecognize that the web client's pulse has terminated. Then, the serverassembly 230 may retain the cache object for a predetermined duration,or until occurrence of a predetermined event, before removing the cacheobject. Retaining the cache object for a predetermined duration, oruntil occurrence of a predetermined event, may ensure that the serverassembly 230 does not prematurely remove the cache object.

At a color change request, various tasks may be performed to effect anew color scheme. The user's cache object may modify a stored colorvalue. The user's web site cookie may be altered with the new colorvalue. The user's web site preferences database field may be updatedwith the new color value. The CSS provided for web site 310 renderingmay change to a CSS specific to the new color value. Additionally, theweb site 310 may be re-rendered using the new web site preference color.

As described above, color changes may be implemented through foldercompartmentalization. Folders may be provided for each color option ofthe web site 310. Accordingly, the web client 124 may dynamically altera color of the web site 310 without requiring a re-login or reloading ofa web page of the web site 310.

Themes may be provided to allow the user to further customize the website 310. A theme may define graphic images and data content presentedto the user. In addition to being stored in the user's database field,the chosen theme may also be stored in the cache object when the user islogged into the web site 310.

When the user selects an available theme, a dynamic update may instructthe application code to display an appropriate set of data and graphicsapplicable to the theme. The theme choice may be implemented through anobject-oriented programming language, and may be processed on thepre-render of page elements.

Photo Management System

As mentioned above, the networking system 300 may further include aphoto management system 380. The photo management system 380 may enableviewing, organizing, and editing images associated with a user account.Such images may include, but are not limited to, photographs andgraphical representations of objects.

With the photo management system 380, a user may have an image libraryon the web site 310, and may utilize an image editor on the web site 310to modify images in the image library. A user may be able to view photolibraries, or predetermined portions of photo libraries, of other users.The user may upload images to the library, and may also create andmodify images in the library. From the image library, the user may sortimages and arrange images in folders for more efficient organization.

The photo management system 380 may include a gallery for viewing imagesin the image library. In the gallery, the user may scroll through allimages, or a set of images, in the image library.

To enable uploading of images, a photo upload dialog may be provided ona web page of the photo management system 380. Through the photo uploaddialog, the user may browse images on, or linked to, the client computer102 and may choose one or more of such photos to add to the imagelibrary. A browser of the photo upload dialog may enable users to viewthumbnails of images on the client computer 102. This may enable theuser to more efficiently select images that the user intends to add tothe image library.

Uploaded or newly created images in the image library may not beimmediately viewable by other users. When uploaded or created, a newimage may have an unapproved status. While approved images may beviewable by others, unapproved images may not be viewable by otherusers. For an image status to change from unapproved to approved, theweb site manager 315 may be required to approve the image. Additionally,an image may not be viewable if it has not been selected as a viewableimage by the user of the image.

The photo management system 380 may require that no more than apredetermined number of images from the user's image library beappointed for each purpose that can be given to images. For example, andnot limitation, the user may be required to select no more than apredetermined number of images viewable by other users, or no more thana predetermined number of images viewable by those other userscategorized as “friends” of the user. The user may appoint an image to acertain purpose by dragging the image into a designated section of a webpage of the photo management system 380.

FIG. 14 illustrates a flow diagram of a process 1400 of managing andediting images in an exemplary photo management system 380. At 1401 and1402, the web client 124 may communicate with a database on the serverassembly 230. At 1404 and 1408, the web client 124 may receive imagedata from the database. The web client 124 may then load images from theimage library at 1410. At 1412, the web client 124 may assign the imagesaccording to their appointments, such as assigning a position of animage in a certain location based on whether the image represents partof the user's viewable profile, or whether the image is viewable only tofriends. The web client 124 may display a graphical user interface tothe user at 1414.

The user may then have an ability to perform actions regarding theimages, as described above. At 1416, the user may modify appointments ofvarious images. At 1418, the user may flip an image. At 1420, the usermay rotate an image. At 1422, the user may delete an image from theimage library. At 1424, the user may assign an image to a particularappointment. After the user selects any one of the above actions, datamay be communicated between the client computer 102 and the serverassembly 230 to accomplish the selected task, and to store the user'smodifications to images on the database of the server assembly 230. Ifthe selected action was successful at 1428, the web site 310 may notifythe user of the success at 1430. Alternatively, if the action failed at1432, the user may be notified of the failure at 1434.

The user may upload images to the image library at 1436. In an exemplaryembodiment of the photo management system 380, a file browser may bedisplayed at 1438 to assist the user in selecting a file to be uploaded.At 1440, the selected file may be prepared for uploading, and at 1442,image data from the selected file may be transmitted from the clientcomputer 102 to the server assembly 230. If this operation is successfulat 1444, a confirmation may be displayed to the user at 1446. Also at1446, the web client 124 may refresh a web page of the image library todisplay the image library containing an image from the selected file.The process 1400 may then, once again, load images in the image libraryat 1410. Alternatively, if the operation of uploading the selected imagefile fails at 1148, an error message may be displayed to the user at1450.

The image editor of the photo management system 380 may enable the userto modify images in the image library. The image editor may includetools to crop an image, rotate an image, flip an image, delete an image,create a photo profile, and various other image-editing tools.

Additionally, the photo editor may provide a tool enabling the user tocreate a thumbnail image, which may represent the user on the web site310. The user may associate the thumbnail image with text, which may beused in conjunction with the thumbnail to represent the user on the website 310. Preferably, the user may have only a single thumbnail image,so creating a new thumbnail may automatically delete any old thumbnail.

The thumbnail tool may enable the user to crop an image to a specifiedsize or to specified dimensions or aspect ratio. To use the thumbnailphoto, the user may first select an image from the image library. Theuser may select a first point on the selected image, and may do so byclicking with a mouse button, with a cursor over the first point, andholding the mouse button down. The user may then select a second pointon the selected image. Selecting the second point may entail draggingthe cursor to the second point while holding the mouse button down, andthen releasing the mouse button with the cursor over the second point.As the first user drags the cursor between the first and second points,a rectangle may be displayed between the first and second point, suchthat the first and second points lie on opposite corners of therectangle. If valid, a portion of the selected image lying inside therectangle may represent a new thumbnail created by the user. Theselected portion may be deemed invalid, however, if, for example, therectangle extends outside the bounds of the image. If the selectedportion is invalid, a new thumbnail may not be created for the user.

FIG. 15 illustrates a process 1500 of editing images with an exemplaryimage editor of the photo management system 380. After the networkingsystem 300 displays the graphical user interface at 1414 (as describedin FIG. 14), the user may edit images as described above. For example,the user may perform any of the following: flip an image at 1556, rotatean image at 1558, delete an image at 1560, and create a thumbnail at1566. At 1526, data regarding the user's image modifications may becommunicated between the client computer 102 and the server assembly230. If the modifications fail at 1532, the user may be informed of thefailure at 1534. On the other hand, if the modifications succeed at1528, the user may be informed of the success at 1530.

At 1562, the user may attempt to crop an image. At 1564 and 1568, theuser may select a portion of the image as described above, with respectto creating a thumbnail. At 1590, the networking system 300 maydetermine whether the selected portion of the image is valid. At 1572,the user may be informed of success or failure of cropping the imagebased on the user's selection. If the cropping was successful, data maybe sent to the server assembly 230 to store the user's modifications tothe image at 1574.

The networking system 300 may store both an original raw image and a setof attributes representing modification to the image. The modificationsmay be a result of photo editing on the part of the user. The attributesmay contain all data required to reconstitute the current image havingthe user's previous modifications. Accordingly, when an image is to bedisplayed on the client computer 102, the raw image may be manipulatedwith the stored attributes before being delivered to the client computer102. FIG. 16 illustrates a flow diagram of an exemplary process 1600 ofdelivering images to the client computer 102 in the photo managementsystem 380.

As shown in FIG. 16, at 1618, the networking system 300 determineswhether the user has requested a rotation of the image. Suchdetermination may occur by examining the stored attributes associatedwith the image. If a rotation is requested, at 1624, the desiredrotation is performed. At 1626, the networking system 300 may determinewhether the image should be flipped. At 1634, the networking system 300may determine whether to perform red-eye reduction and, at 1636, whethersuch red-eye reduction is to be performed manually or automatically. Thenetworking system 300 may then use the attributes to re-perform thered-eye reduction as originally performed. If a manual red-eye reductionwas performed, characteristics of such reduction may be retrievable fromthe stored attributes.

At 1642, the networking system 300 may determine whether color levelsshould be modified. If so, at 1644, the networking system 300 maydetermine whether the user desired manual or automatic modification ofcolor levels. At 1650, the networking system 300 may determine whetherto modify brightness and contrast of the image and, at 1652, whethersuch modifications are manual or automatic. At 1654 and 1656, thenetworking system 300 may perform the requested modifications. Finally,at 1658 the resulting image is returned.

The image may be at least partially defined by image manipulationarguments, which may reflect the user's modifications to the image. Theserver assembly 230 may store each image as well as one or more sets ofimage manipulation arguments. The image manipulation arguments may bestored in a table or array along with a reference to the associatedimage. Each set of manipulation arguments for the image may define adisplayable image created through a set of user manipulations to theoriginal image. For example, a user may create a thumbnail from theoriginal image to identify the user on the web site 310. The user mayalso rotate and crop the original image for display in the user'sprofile. Depending on whether the web site 310 is displaying thethumbnail version of the image or the profile version of the image, thenetworking system may apply a different set of manipulation arguments tothe image when displaying the image on the web site 310.

Preferably, the image manipulation arguments define modifications to theimage in a coordinate system of the image. For example, if the userrotates and then crops the image, both operations may be stored in a setof image manipulation arguments with reference to coordinates relativeto one or more points on the image. This enables appearance of the imageto be independent of an order in which the rotation and cropping areapplied to the image before the image is displayed. If, in contrast,operations are stored with reference to an absolute coordinate system,then reconstituting the modified image would require performing theoperations in the order in which the user originally performed suchoperations. The present photo management system 380 may allow moreflexibility by enabling operations within a set of manipulationarguments to be stored in various orders.

A second set of arguments, display arguments, associated with an imagemay be provided to define how the web client 124 may manipulateformatting and display of the image. For example, although the image maybe stored in a size of 800×600 pixels, the web client 124 may displaythe image into a 320×200 display area. Accordingly, display argumentsmay instruct the web client 124 to shrink the image to fit in a 320×200display area.

FIG. 17 illustrates a flow diagram of a process 1700 of displaying animage in the photo management system 380. At 1701, the user may requestthat an image be displayed. Accordingly, the networking system 300 mayretrieve the image from storage on the server assembly 230 at 1702 and1704. At 1706, the networking system 300 may determine whether there areany display arguments for the image. At 1708, the networking system 300may determine that display arguments should be applied to the image, andsuch arguments are applied at 1710. After the display arguments havebeen applied, or after the networking system 300 determines that displayarguments need not be applied, at 1712, the networking system 300 maydetermine whether the user requested any user manipulation arguments forthe image. If user manipulation arguments exist for the image, thenetworking system 300 may manipulate the image according to the usermanipulation arguments beginning at 1610 (FIG. 16). Finally, at 1714,the image may be displayed to the user.

Image caching may be provided in the photo management system 380 of thenetworking system 300. Caching may result in efficient image loading,while maintaining conventional benefits of retaining stored images onthe database, such as reliable long-term storage. When a web client 124requests an image from the networking system 300, the image may bemodified by parameters of the stored attributes before the image isdelivered to the web client 124 at the client computer 102. Images aremodified by the processing server using a series of parameters providedwhen a request is made. After all modifications are complete, the imagesmay be saved to a cache server, which may comprise a storage deviceassociated with a server in the server assembly 230. Use of the cacheserver to store the modified image may reduce or eliminate the need forthe server assembly 230 to repetitively process the image beforedisplaying it. Data in the cache server may be disposable and,accordingly, may be removed from the cache server when the user logs outor when space is needed. The storage device may be implemented in aRedundant Array of Inexpensive Disks (“RAID”) array to enhance speed,capacity, and performance of the storage device.

Image caching may relieve the server assembly 230 of potentiallyextensive processing of the image, by writing the image to the storagedevice after the image has been modified according to its associatedstored attributes. If the image is requested again, the networkingsystem 300 may retrieve a cached copy of the image from the storagedevice instead of from a database on the server assembly 230.

A benefit of image caching is stateless replication, which enables newservers to be added to the server assembly 230 without replicating anexisting cache. Conventionally, each server would be required toreplicate caches of other servers, and to synchronize its cache withother servers. This utilizes time and bandwidth. In exemplaryembodiments of the photo management system 380, however, the new serverwould not be required to synchronize cached images with other servers ofthe server assembly 230. For example, if a requested image does notexist on a storage device of the new server, the image may be retrievedfrom the database, modified, and

Messaging System

As mentioned above, the networking system 300 may further comprise amessaging system 390. The messaging system 390 may enable a first userto leave a message for a second user of the networking system 300. Forexample, the messaging system 390 may enable a common user 415 to leavea message for a featured user 435, such that the featured user 435 mayview and respond to the message at the convenience of the featured user435. A featured user 435 may also leave a message for a common user 415.Additionally, a common user 415 may leave a message for another commonuser 415, and a featured user 435 may leave a message for anotherfeatures user 435.

FIG. 18 illustrates an exemplary web page of the messaging system 390.As shown in FIG. 18, the messaging system 390 may comprise a messagearea 1810, at least one graphical tool 1820, and a color selector 1830.

The message area 1810 may provide a background for the message. In someexemplary embodiments of the messaging system 390, the message area 1810may look similar to a whiteboard, blackboard, piece of paper, computermonitor, or various other objects on which one might conventionallyleave a message or receive a message. The look and feel of the messagearea 1810 may be customizable. For example, and not limitation, thefirst user may change an appearance of the background provided by themessage area 1810 by clicking a button labeled “Background” on the webpage.

In an exemplary embodiment of the messaging system 390, the message area1810 of a particular user may retain text and images left by previoususers of the same message area 1810. Accordingly, when the first userviews the web page displaying the second user's message area 1810, thefirst user may see messages previously left by the first user and byother users.

The graphical tools 1820 may comprise one or more representations ofimplements for creating the message. For example, a stylus 1822 and aneraser 1824 may be provided as graphical tools 1820. Other graphicaltools 1820 provided may include, without limitation, a text tool, abrush tool, a spray paint tool, a straight line tool, a rectangle tool,and a circle tool. When activated, the stylus 1822 may add portions of amessage to the message area 1810, while the eraser 1824 may removeportions of a message from the message area 1810.

Characteristics of the graphical tools 1820 may be customizable. Forexample, a size and shape of a graphical tool 1820 may be customizable,which may result in a customizable size and shape of modificationsresulting from use of the graphical tool 1820. For example, increasingthe size of the stylus 1822 may increase a width of a line drawn in themessage area 1810 with the stylus 1822. Additionally, transparency of agraphical tool 1820 may be customizable, such that a resultingmodification to the message area 1810 may become more or less opaque.Customizations may affect a single graphical tool 1820 or,alternatively, all graphical tools 1820, depending on either userpreference or a specific embodiment of the messaging system 390.

The color selector 1830 may present the first user with two or morecolor blocks 1835 containing colors applicable to one or more graphicaltools 1820. Each color block 1835 may be a predetermined color. When thefirst user selects a color block 1835, the color of the color block 1835may be applied to the graphical tool 1820 next utilized in the messagearea 1810. A default color may be provided if the first user does notselect a color block 1835. For example, a black color may be applied tographical tools 1820 when the first user does not select a color block1835.

Additionally, the color selector 1830 may allow the first user to adjustcharacteristics of a color, such as hue and saturation, and therebycreate a custom color for application to a graphical tool 1820.

A message of the messaging system 390 may be created by manipulating agraphical tool 1820 on or in proximity to the message area 1810. Thefirst user may select a graphical tool 1820 and, optionally, a color.When the first user activates the graphical tool 1820, such as byclicking a mouse button, the graphical tool 1820 may be applied to themessage area 1810, thereby modifying a visual appearance of the messagearea 1810. For example, when the stylus 1822 is activated, moving thestylus 1822 across the message area 1810 may result in a line beingdrawn along a path of the stylus 1822 in the message area 1810. Forfurther example, when the eraser 1824 moves across the message area1810, text and images in a path of the eraser 1824 may be removed fromthe message area 1810. The modified visual appearance of the messagearea 1810 represents a viewable message. The message may comprisevarious combinations of text and images in the message area 1810, andmay or may not be intended to portray a specific idea to a recipient ofthe message.

During message creation, the first user may be able to save the message.This may be enabled, for example, through use of a web page button orlink labeled “Save.”

Further, the first user may be able to undo a previous action. This maybe enabled, for example, through use of a button or link labeled “Undo.”In some exemplary embodiments of the messaging system 390, an action maynot be undone if the action preceded a saving of the message, asdescribed above.

FIG. 19 illustrates a flow diagram of an exemplary process 1900 ofleaving a message, such as a text comment, through the messaging system390. As shown in FIG. 19, three layers of operation may be implementedin the messaging system 390. These operational layers may include a userinterface layer 1902, an application layer 1904, and a database layer1906. Steps of the process 1900 occurring in the user interface layer1902 may describe an interaction of the messaging system 390 with theuser. Steps of the process 1900 occurring in the application layer 1904may represent operations that occur in the client computer 102. Finally,steps in the database layer 1906 may occur in a database on the serverassembly 230.

At 1910, the first user may enter a text comment for the second user.This may occur through use of the stylus 1822. After such text isproduced, the text is stored as a record in a database on the serverassembly 230 at 1920. Accordingly, at 1930, the text may be retained ina table of the database and properly associated with a message area 1810of the second user. At 1940, the new text comment may be rendered.Rendering may generally take place behind the scenes of the web page,and a rendered image may not be viewable until displayed on the webpage. At 1950, the new text comment may be displayed in the message area1810, which may occur by making viewable a rendered image of the textcomment.

FIG. 20 illustrates a flow diagram of an exemplary operation 2000 ofretrieving a message, such as a text comment, from the messaging system390. As in FIG. 19, three layers of operation 1902, 1904, and 1906 maybe utilized in retrieving a message. At 2010, the first user may requestthat a text comment be displayed. Such a request may be implied when thefirst user navigates to a web page displaying the message area 1810. Therequest may be transmitted through the messaging system application, at2020, to the database. At 2030, the text comment may be retrieved fromthe database. The messaging system 390 may then render the text comment,preferably in HTML format, at 2040. Finally, at 2050, the text commentmay be displayed to the first user.

FIG. 21 illustrates a flow diagram of an exemplary general operation2100 of the messaging system 390. At 2101 and 2102, the web client 124may communicate with a database on the server assembly 230 regardingmessage data. At 2104 and 2107, the web client 124 may receive messagedata from the database. The web client 124 may then display thegraphical user interface (“GUI”), including the message area 1810, viathe web client 124 to display messages to a user. At 2110, the messagingsystem 390 may determine whether the user is attempting to leave acomment in the message area 1810. If so, the user's comment is acceptedat 2112. Otherwise, an empty comment is accepted at 2113.

At 2114, a record may be created in the database for storing thecomment. At 2116 and 2126, the web client 124 and the server assembly230 may communicate with each other. The web client 124 informs theserver assembly 230 of modifications to the message area 1810, so thatthe database on the server assembly 230 may be updated. The serverassembly 230 may then send a confirmation to the web client 124. At2118, the GUI may be update to display the new comment to the user.

Operations similar to those of the image editor of the photo managementsystem 380 may also be integrated into the messaging system 390. Forexample, and not limitation, at 2122, the user may select a tool tomodify the GUI. Specifically, the user may modify the message area 1810by leaving a message. After a modification, the GUI may be updated todisplay the modifications to the user.

If the user indicates that he would like to save his modifications tothe message area 1810, the messaging system 390 may receive a command tothe save at 2120. The web site 310 may prompt the user for confirmationat 2121. If the user confirms his desire to save, an image of themessage area 1810 may be sent to the server assembly 230 at 2124. At2126, the database on the server assembly 230 may be updated with theuser's modifications. Hence, the user may leave a message in the messagearea 1810, and may save his message for later viewing. After thedatabase is updated, the message application 1904 may close at 2128.

Accordingly, through implementation of the crediting system 320, thechat bidding system 330, the performance bidding system 340, thetelephony switching system 350, the media interaction system 360, thedisplay system 370, the photo management system 380, and the messagingsystem 390, the networking system 300 may enable interaction betweenusers.

While the networking system 300 has been disclosed in exemplary forms,it will be apparent to those skilled in the art that many modifications,additions, and deletions may be made without departing from the spiritand scope of the system, method, and their equivalents, as set forth inthe following claims.

What is claimed is:
 1. A method of hosting user performances, the methodcomprising: receiving a plurality of performance requests, eachperformance request comprising a performer identification and aperformance bid value; storing the plurality of performance requests ina performance queue; selecting a first performance request of saidplurality of performance requests by selecting the performance requesthaving the largest performance bid value; notifying a first userassociated with the performer identification associated with the firstperformance request; receiving first performance data from the firstuser; and displaying the first performance data.
 2. The method of claim1, wherein the first performance data comprises digital video data. 3.The method of claim 1, further comprising displaying song lyrics to thefirst user.
 4. The method of claim 1, wherein the first performance datacomprises audio data.
 5. The method of claim 1, further comprisingreceiving a request to modify a performance bid value associated with afirst performance request of said plurality of performance requests. 6.The method of claim 1, further comprising: storing the first performancerequest in a standby queue; removing the first performance request fromthe performance queue; selecting a second performance request of saidplurality of performance requests by selecting the performance requesthaving the largest performance bid value after the first performancerequest was removed from the performance queue; storing the secondperformance request in a standby queue; removing the second performancerequest from the performance queue; notifying a second user associatedwith the performer identification associated with the second performancerequest; receiving performance data from the second user after the firstperformance data is finished being displayed; and displaying the secondperformance data.